Hi, I'm hoping Morten C. or Sabastiaan J. can help shed some light on Umbraco direction with respect to APIs. New APIs are being rolled out with V6.0.0 and so can you please provide vision to Umbraco's API future with these?
Specifically, IContent is now the new all-important representation of documents, but IPublishedContent is still a de-facto object interface provided through Razor (Model.Content)? These two interfaces have no relation to one another (they do not inherit), I cannot 'adapt' IContent object into IPublishedContent to pass to functions or libraries that expect IPublishedContent, but I can do so the other way via GetById() lookup.
I suppose what I am asking is: Where should I be putting my effort at the moment if I'm about to build a new Umbraco based site? Should my razor views not use the Model.Content but instead call on ApplicationContext.Current.Services.ContentServices.... for the usual query and navigation? Will Model.Content eventually consolidate into IContent or is IPublishedContent here to stay?
Having some idea to the direction of where Umbraco is heading would really help toward future proofing. Converting my current implementation (4.11.1) into 6.0.0-RC was not exactly trivial so I'd like to know where to focus effort now that I'm about to begin the bulk of my razor logic.
The IContent and IPublishedContent objects comes from two different API's that has two different purposes. So you should put your efforts on both of them. Both IContent and IPublishedContent are here to stay.
The ContentService, MediaService and all the other services and the models that are used within them are intended for manipulating content. This is the API the backoffice uses to create, save and publish content (among other things). So if you need to create content from your code then this is what you'll use. You should not use these services from your Views as they typically hit the database and therefore not intended for rendering content. If you need to programmatically create content or just update content because of some action that occured then you should place that code in a controller (if we talking MVC) .
IPublishedContent is for rendering and querying published content in your views on the frontend. The content is served from the xml cache and is therefore better suited for querying. So for serving up content from Umbraco IPublishedContent is what we'll focus on for MVC (Model.Content). You can still continue to use dynamics in your views if you prefer that (CurrentPage). And a side note: IPublishedContent is read-only.
After profiling queries via AncestorOrSelf() vs. ContentService, I found that using the ContentService to retrieve data for rendering is ALOT faster. This is because the recursive search that AncestorOrSelf does is slow vs. the table scan that the ContentService does.
FYI,
var result = AncestorOrSelf.Decendants("MockAlias")
VS.
var mockAliasId =ContentTypeService.GetContentType("MockAlias")
var result = ContentService.GetContentOfContentType(mockAliasId)
Are you getting similar results? If so, my question is why should I use IPublishedContent instead of IContent, it seems I can get what I need faster via the new api services?
Hi, Its good to hear that the ContentService performs well, but I need a bit more context around your usage of AncestorOrSelf() and IPublishedContent in order to give you a proper reply. Is it possible for you to post a bit more code with your usage of IPublishedContent? Preferably the part you found slower. The bit you posted is a bit to abstract.
Umbraco API Direction: Where to with 6.0.0?
Hi, I'm hoping Morten C. or Sabastiaan J. can help shed some light on Umbraco direction with respect to APIs. New APIs are being rolled out with V6.0.0 and so can you please provide vision to Umbraco's API future with these?
Specifically, IContent is now the new all-important representation of documents, but IPublishedContent is still a de-facto object interface provided through Razor (Model.Content)? These two interfaces have no relation to one another (they do not inherit), I cannot 'adapt' IContent object into IPublishedContent to pass to functions or libraries that expect IPublishedContent, but I can do so the other way via GetById() lookup.
I suppose what I am asking is: Where should I be putting my effort at the moment if I'm about to build a new Umbraco based site? Should my razor views not use the Model.Content but instead call on ApplicationContext.Current.Services.ContentServices.... for the usual query and navigation? Will Model.Content eventually consolidate into IContent or is IPublishedContent here to stay?
Having some idea to the direction of where Umbraco is heading would really help toward future proofing. Converting my current implementation (4.11.1) into 6.0.0-RC was not exactly trivial so I'd like to know where to focus effort now that I'm about to begin the bulk of my razor logic.
Kind regards. VM.
Hi Vojin,
The IContent and IPublishedContent objects comes from two different API's that has two different purposes. So you should put your efforts on both of them. Both IContent and IPublishedContent are here to stay.
The ContentService, MediaService and all the other services and the models that are used within them are intended for manipulating content. This is the API the backoffice uses to create, save and publish content (among other things). So if you need to create content from your code then this is what you'll use.
You should not use these services from your Views as they typically hit the database and therefore not intended for rendering content. If you need to programmatically create content or just update content because of some action that occured then you should place that code in a controller (if we talking MVC) .
IPublishedContent is for rendering and querying published content in your views on the frontend. The content is served from the xml cache and is therefore better suited for querying. So for serving up content from Umbraco IPublishedContent is what we'll focus on for MVC (Model.Content).
You can still continue to use dynamics in your views if you prefer that (CurrentPage).
And a side note: IPublishedContent is read-only.
Hope this helps answer your question.
- Morten
Thank you for the very comprehensive answer, it makes good sense, and certainly clears up the confusion (hope it also helps others!).
Thanks Morten.
Hi Morten,
After profiling queries via AncestorOrSelf() vs. ContentService, I found that using the ContentService to retrieve data for rendering is ALOT faster. This is because the recursive search that AncestorOrSelf does is slow vs. the table scan that the ContentService does.
FYI,
var result = AncestorOrSelf.Decendants("MockAlias")
VS.
var mockAliasId =ContentTypeService.GetContentType("MockAlias")
var result = ContentService.GetContentOfContentType(mockAliasId)
Are you getting similar results? If so, my question is why should I use IPublishedContent instead of IContent, it seems I can get what I need faster via the new api services?
Hi, Its good to hear that the ContentService performs well, but I need a bit more context around your usage of AncestorOrSelf() and IPublishedContent in order to give you a proper reply. Is it possible for you to post a bit more code with your usage of IPublishedContent? Preferably the part you found slower. The bit you posted is a bit to abstract.
Thanks,
Morten
I have a content structure similar to
- Home
---- MockParent
------ MockChild
--------- MockGrandChild1
--------- MockGrandChild2
--------- MockGrandChild3
I was looking at the time taken to retrieve all MockGrandChild nodes via
1)
// The currentPage variable below comes via a controller param, when hi-jacking a route (RenderModel)
var result = currentPage.AncestorOrSelf().Decendants("MockGrandChild")
VS.
2)
var mockAliasId = ContentTypeService.GetContentType("MockGrandChild")
var result = ContentService.GetContentOfContentType(mockAliasId)
Hi Morten just wondering what would be the best convention to get a url of an item returned by the contentservice?
is working on a reply...