Try our conversational search powered by Generative AI!
AI OnAI Off
data objects instead of pages
Hi @Paul, thank you for your response.
I'm very famililar with the DDS, and it's very easy to use as a standalone feature, but considering the EPiServer pages handle their own storage in the database, there would need to be some code which specifically handles storing information in the DDS when an editor saves the page, but that is not simple code, and comes with issues in real world situations.
For instance, as data entries, instead of pages, we may be intergrating with 3rd Party API's to pull in more information (part of why I'm trying to think of it as data rather than pages), but then if the DDS is updated from outside the CMS, how are those changes loaded into the page when an editor later loads that page and expects to see the new information already intergrated into the page?
Another, probably related issue, is how do I, when in 'EditMode' in the CMS, allow some fields to be ('traditional') page data fields while some other data fields are loaded from the DDS. If I could someone show input boxes in the CMS that are NOT 'episerver style' page properties, but were instead ONLY saved in the DDS, then most of the job would fall into place.
but anyway, as with most coding, I'm sure I could find a complicated, lenghty-to-develop, hard-to-understand (and thus maintain) DDS solution to solve these issues, but then it kinda loses all it's benefits, as much of this is myself trying to use good programming strategies to solve several issues at once, rather than trying to code to an ideology (data instead of pages) and creating a complicated solution to accomodate that approach.
Is there an easy way I could include extra fields in 'all properties' view that are not actually 'episerver style' page properties? (without having to dive into Dojo javascript?)
Does anyone know how other people have appoached this sort of requirement?
Dec 06, 2018 18:21
Hi,
I am not sure to understand your requirement completely. But if you want store and show a list of simple items in a page then you can use PropertyList type.
I hope that this link is helpful for you https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2015/11/trying-out-propertylistt/
Dec 10, 2018 7:21
Being fairly new to Episerver, I've encounter requirements where we are listing data on a 'front page' that then lets you click each item and drill down for more information, and as is the nature of lists of items, sometimes it feels appropriate to create different 'views' of the data (e.g. 'show me all products suitable for x. y or z', or 'list only yellow items' etc etc). But up to this point, we've always used 'child pages' for these instances, and then made use of EPiFind or "get children()" methods to then inspect, list or project the data as we need it.
Coming from a more traditional (database heavy) development, if feels like the data we are listing, or drilling down into, should be abstracted away from pages and be handled as data objects themselves.
Bearing in mind the editor experience, and complexity of design (we'd like to keep it simple), have other people encountered this situation, and does anyone have any advice or could recommend some 'best practices' regarding solving this sort of set of requirements?