This blog post explains how you can model Group FIelds in Entry Model classes as Group Model Classes that are just like Block Model Classes for Modular Blocks, but without all the JsonConverters. You can use the same technique to model Contentstack Global Fields, which are basically reusable Field Groups.
I do not mean to promote Contentstack over any other CMS, but these explain the concepts well and I do not want to repeat. Other vendors, please comment with your corresponding links and I will add them.
- https://www.contentstack.com/docs/developers/create-content-types/group/
- https://www.contentstack.com/docs/developers/global-field/group-fields-within-global-fields/
- https://www.contentstack.com/docs/developers/global-field/
If the Group can repeat, then in the Entry Model class, can use List<TGroupModel> for the property that models that field, where T is the Group Model to use for a property that represents a single Field.
The code that follows honestly demonstrates what I consider to be the most powerful, efficient, productivity-enhancing, logical, error-avoiding, and intelligent coding models that I have ever seen. This Group Model models the Contentstack JSON that convey Entry publishing status.
In the following Group Model for a Contentful Global Field that contains Fields common to many types of pages and hence many Content Types, you can see some of the repository abstraction that I have mentioned. I don’t want to access vendor SDKs here. Unfortunately, there is no generic .NET interface for (CMS) repositories, so IMadeUp IRepository.
You can also see that this is going to let the Entry Model specify the view for the controller to invoke, and in that view, a partial view to invoke, both using the Entry Model. With Contentstack Modular Blocks, this supports nesting, where those nests can be inline Content Blocks and/or referenced Entries.
Finally, you can see that I am still evaluating various ways to access referenced Entries, for which storage may vary by platform and different techniques might suit different implementations, such as inlining referenced Entry JSON.
I should have mentioned previously, for Assets, inlining referenced Asset metadata into the JSON representation of an Entry can improve performance and developer convenience. It could also allow properties (basically, child Fields such as the value for the alt attribute of an image) in Asset Fields in the CMS to override metadata in the Asset itself, which is really just another type of Entry. So check if the CMS can inline Asset metadata when you retrieve Entries.
I still think it is best to retrieve and cache individual Entries otherwise.
Deliverystack.net 