Recently I had product catalog that was in a external database that I needed to show on the website.
What I did was create a doctype called "Product details" that had all the properties I need to display. Even had my compositions like SEO metadata, Open Graph, etc...
I added a content finder to match the product detail url to a product from the database.
In the content finder I create an instance of IPublishedContent implementation that sets all the properties with data from my product catalog db.
Big advantage is that this is done early in the pipeline. So I can reuse my existing views for seo, open graph, .... etc without having to care where the data is coming from.
I wrote some thoughts about that over in @matt's post. Quoted below for reference.
In any case, when NuCache hits production and (whatever) models are cached across requests, we need a way to intercept the model creation. This is the extension point where we can choose our mapper or add stuff to an adapter (like 1-2). We just have to start minding that it will be cached.
I imagine that extension point might just be your own implementation of IPublishedContentModelFactory, but an event or something more concrete would also make sense. Maybe a virtual Create
Had that page open in a tab for ever, so going to add a few cents to the discussion. In v8, with NuCache, the idea is that each raw IPublishedContent goes through the IPublishedModelFactory, and it's the outcome which is cached.
The benefit being, instead of re-creating models all the time, we keep re-using the same instance. And, it simplifies caching of property-value-converted values.
So, basically, IPublishedModelFactory produces a strongly typed model of content items as they are in the database.
Now, I understand that some ppl used to "enrich" the models with things that would be request-dependent. I am not talking about creating your own IPublishedContent for specific content (such as the products example above) - that will actually be simpler in v8, but a true "out of the blue" IPublishedContent is not impacted by models. I am talking about retrieving a model from cache, and adding stuff to it - that will not work anymore.
I think I like the idea of separating concerns: the model, as returned by the cache, is purely a readonly view of the database content. Now it could be that we indeed need some sort of hook to let ppl wrap this model in a per-request "super model" or something?
I think I like the idea of separating concerns: the model, as returned by the cache, is purely a readonly view of the database content. Now it could be that we indeed need some sort of hook to let ppl wrap this model in a per-request "super model" or something?
By my reckoning, the models should be purely a readonly view of the database (It's a shame setters are required) since the query is a readonly scope one anyway.
I would expect any further manipulation to take place in a view model.
How will the NuCache influence model alteration in the pipeline
Hi,
this is a follow up for this twitter discussion : https://twitter.com/mattbrailsford/status/1004298568218365952
If understand correctly with nuCache your strongly typed model will be cached. So making changed to data will also be cached.
We often add data or even change the model in the pipeline in v7. I added a small example in this article : https://24days.in/umbraco-cms/2016/getting-started-with-modelsbuilder/
Recently I had product catalog that was in a external database that I needed to show on the website.
What I did was create a doctype called "Product details" that had all the properties I need to display. Even had my compositions like SEO metadata, Open Graph, etc...
I added a content finder to match the product detail url to a product from the database. In the content finder I create an instance of IPublishedContent implementation that sets all the properties with data from my product catalog db.
Big advantage is that this is done early in the pipeline. So I can reuse my existing views for seo, open graph, .... etc without having to care where the data is coming from.
Will this be possible in V8 with the nuCache ?
Dave
Some more use cases of changing the model in the pipeline
Blog from Moriyama about archived content : https://www.moriyama.co.uk/about-us/news/blog-the-need-for-archived-content-in-umbraco-and-how-to-do-it/
uSplit package that uses content prepared event for A/B testing : https://github.com/EndzoneSoftware/uSplit/blob/master/src/Endzone.uSplit/Pipeline/ExperimentsPipeline.cs#L34
How will these be affected ?
Dave
I wrote some thoughts about that over in @matt's post. Quoted below for reference.
I think after my holidays i will take V8 for an extensive test.
And see what's possible and not.
I think key will be to document these kind of breaking changes when the final version is released.
Dave
Had that page open in a tab for ever, so going to add a few cents to the discussion. In v8, with NuCache, the idea is that each raw IPublishedContent goes through the IPublishedModelFactory, and it's the outcome which is cached.
The benefit being, instead of re-creating models all the time, we keep re-using the same instance. And, it simplifies caching of property-value-converted values.
So, basically, IPublishedModelFactory produces a strongly typed model of content items as they are in the database.
Now, I understand that some ppl used to "enrich" the models with things that would be request-dependent. I am not talking about creating your own IPublishedContent for specific content (such as the products example above) - that will actually be simpler in v8, but a true "out of the blue" IPublishedContent is not impacted by models. I am talking about retrieving a model from cache, and adding stuff to it - that will not work anymore.
I think I like the idea of separating concerns: the model, as returned by the cache, is purely a readonly view of the database content. Now it could be that we indeed need some sort of hook to let ppl wrap this model in a per-request "super model" or something?
By my reckoning, the models should be purely a readonly view of the database (It's a shame setters are required) since the query is a readonly scope one anyway.
I would expect any further manipulation to take place in a view model.
is working on a reply...