Developer forum

Hey Imar

I can throw you a quick answer on this, as I asked the same question in this thread: http://doc.dynamicweb.com/forum/feature-requests/itemservice-getitems?PID=1605 :)

You need to use the pageService (Dynamicweb.Services.Pages) instead, and then you just use page.Item to get the item of the given pages.

Ah, I see. That makes sense. I was looking for methods that would return an item, not for a page that exposed an item.

Thanks!

Imar

Hi Imar (and Claus),

Im curious why you would need to fetch an Item, but not a page? Just so I can understand your use-case and hopefully come up with an easy way to support it in the future.

BR

Martin

Hej Martin

Under a page I might have 2 different item type pages - and only be wanting to list one of the types on a page, so where I before was running through the items of the type I needed, I now run through the pages, and filter based on the item I need. So I usually also want the page, which is why the new solution works fine for me, I simply had not seen that it had been changed and I guess the helping text was worded in a way I did not find helpfull at first, I was thinking, "why is it telling me how to get pages when I want items?", granted it was late at night :)

Hi Martin,

I can explain one of our use cases.

We sometimes use Items to store various settings or functionalities that expose a UI to the user. We never use that data in a published form. Like a visible page in the froint-end, but rather as another "settings" section. This si often used for things that are not supported by default in DW but are required in the implementation. ItenmTypes offer a simple and editable way of defining UserInterfaces for the admins, which makes it particulalrly useful for extending DW.

In those case, we just don;t need the page object because we are only using the values store in the ItemDefinition. Whatever is stored in the corresponding ItemType_ table. But in order to get there, we need to identify the Item based on a Page object first, then retrive the properties of the item.

Sometimes the restriction that you can only access the item only if it's published as a page, paragraph or ItemList, makes it even hard to use it as an extensibility.

Does it make sense?

Adrian

Thanks for stepping in, Adrian. That makes a lot of sense. Not sure if you knew, but there's a method called GetPageByNavigationTag on the IPageService that returns the page by the navigation tag set on the page's properties so you can have settings per site easily:

      var pageService = ServiceLocator.Current.GetInstance<IPageService>();
      var settingsItem = pageService.GetPageByNavigationTag(areaId: 1, "Settings").Item;

It does require to fetch the full page though, which I think is the issue we'e dscussing here. Not sure - other than unexpected syntax maybe - how big of a problem that is since I assume the page comes from the cache, right?

Imar

And further to what Claus said:

I simply had not seen that it had been changed and I guess the helping text was worded in a way I did not find helpfull at first

That's what I ran into as well. I can work with the new syntax; it's just that the Obsolete attribute didn't tell me *how* to the use the PageService to get the same functionality.

Imar

Hi Claus, Adrian and Imar,

Thanks for the explainations. This immensely helps me understand how the api is being used (which is often more important than how we think it should be used!). :)

Adrian: I think that an item belonging to a page should be considered to be part of the page. Not something seperate - being able to fetch an item from a page that was not published, was never our intended purpose for items, and also makes it much more difficult to handle if the data contained in the Page (and therefore item) should be exposed to the frontend. Fx. marking a page as "not published" should hide the item aswell. How else are you going to be able to unpublish this item from your list of data?

Claus, Imar: I think the confusion is because of naming. Items and Pages have a 1 to 1 relation. This means, that Page and Item are one. Since Items are basically just a key/value collection, it's only convinient to work with pages - something with an easy to identify id.

Adrian, Claus and Imar: Please let me know if you prefer to work with the api in a different way - as you can see, Im not afraid of changes to api working habits. ;)

BR

Martin

Hey Martin

I think a few words on the api changes, when they happen would be the biggest help - maybe just a page similar to your bug fixes that say "we changed this for this reason", I get the page/item similarity, one could be tempted to just call them a node :) but the process is just very different from before where they lived 2 very sepearate lives, as pages more often excisted without an item. So ye - dokumentation is proberbly what we are mostly requesting in this case.

Yeah, I second what Claus said. And in addition, if the Obsolete attribute had a one-liner explaining which method to call, that would have solved it for me too. I'm fine with the API as it is today, and I don't mind fetchign a page to then access its Item.

Thanks,

Imar

Hi Claus and Imar,

Just to clarify: What I described is not a change. It's how NP envisioned Items and Pages from the get-go. They morphed into something more generic over time, and we need to defined how these "generic things" are to be used, since they are being used in a way that is so divergent from how they where designed.

I personally think we need a unified "item-like" thing in our system, that can fulfil the use-cases you have, but the ItemManager is simply not built with this in mind - this might change in the near future, when we plan our refactoring of Items and ItemTypes (probably during 9.5).

I will try to make documentation a priority - or at least make something that clearly shows how our changes are meant to be used.

BR

Martin

I just thought of a small clarification: If we obsolete a method without a hint, this means that we think that it is a method that should never have been used in the first place (or that we forgot, but most often we remember). This is a clear hint that you're doing something that would be great to write a forum-post about, such that we can do the following:

1. Understand your use-case

2. Change the API to support the use-case (OR help design a different approach that uses the api in the way we thought you where going to use it) ;)

3. Explain why we obsoleted the method, without giving a hint (we should always be able to explain why things got obsoleted, but a hint-text is not a place to write a long story about the considerations involved)

BR

Martin

For big, impacting changes, a blog post would be great. For smaller ones, just a better Obsolete reason would be sufficient, I'd say.

Imar

Hi Martin,

Here's another great example of how an Obsolete attribute can help. I just upgraded to 9.4 and now get this:

Line 766: 'Dynamicweb.Ecommerce.International.CountryText' does not contain a definition for 'GetRegionTexts'
Line 780: 'Dynamicweb.Ecommerce.International.CountryText' does not contain a definition for 'GetCountryTextById'
Line 2241: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2259: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2266: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2271: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2353: 'Dynamicweb.Ecommerce.International.Country.GetCountries()' is obsolete: 'Use Ecommerce.Services.Countries.GetCountries() instead'
Line 2374: 'Dynamicweb.Ecommerce.International.Country.GetRegions(string)' is obsolete: 'Use Ecommerce.Services.Countries.GetRegions(countryCode) instead'
Line 2372: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2421: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'
Line 2446: 'Dynamicweb.Ecommerce.International.Country.CountryText' is obsolete: 'Is not used'

Line 7 and 8 are super useful and allowed me to fix the issue in seconds. What about the others? What does "Is not used" mean? It certainly was used by us! ;-) Is there an alternative to using CountryText and RegionText?

Congratulations on the release of 9.4. Just started poking around a bit and I really like what I see!

Imar

Hi Martin,

I am refactoring Dynamicweb.Ecommerce.International.CountryText.Name to Dynamicweb.Ecommerce.Services.GetLocalizedName().

So far so good, but etLocalizedName() takes a required languageId parameter. Can we make that optional?

I am currently using Pageview.Are.EcomLanguageId to get it, but I haven't figured out if that value is consistent or updated when the user updates the ecomlanguageId through the querystring (adding &languageId=LANG2). Bottom line is, if the parameter would be optional, it could take the current context, without the developer having to code it.

Best Regards,

Nuno Aguiar

HI Martin,

You are accurate. I did not cop the entire method path. This is how I am using it 

Dynamicweb.Ecommerce.Services.Countries.GetCountry(countryCode).GetLocalizedName(Pageview.Area.EcomLanguageId);

And I understand the stateless context.

Thank you,

Nuno Aguiar

Hi Martin,

I inspected the property and 'yes' it does what I need since it's context aware. Thanks.

Nuno Aguiar