This blog post continues (maybe a bit repetitiously) the rant that I started at https://deliverystack.net/2020/07/21/contentful-net-sample-entry-model/. In that post I mentioned some of the implications of Contentful’s representation of the value of Rich Text Fields in a proprietary JSON format rather than XHTML, and some of the technical implications of that implementation. I understand the intention, but it is unnecessary. This blog post lists some additional reasons why I object to the approach taken by this vendor for this feature.
As a (.NET Core) (web) Content Management Systems implementor, in my primary and possibly only use case for retrieving a value from a Rich Text Field, there is not a single condition under which I would prefer to retrieve JSON in a custom format rather than markup in a standard format. If I want to embed custom data in the markup, I can use custom XML elements and attributes, XML comments, JSON embedded in <script /> elements or otherwise, or other features supported by markup. If I want to transform data in the markup, for example to open all links to external sites in new browser tabs or ensure that images have proper attributes, I can use HtmlAgilityPack (https://html-agility-pack.net/).
- Even if the JSON format is efficient, this must increase the RESTful API payload size to retrieve an item, as well as memory consumption (especially if I want to cache this data before and after converting it to HTML) and CPU time for transformation. I wonder if this format could be efficient in the vendor’s native storage system or for specific search/indexing or other scenarios.
- I do not want to expose or even use the vendor’s proprietary JSON format or SDK in my Entry Models.
- I want to use the same Entry Model classes regardless of the CMS.
- I would prefer to avoid adding additional layers of complexity.
- Maybe I can implement a JsonConverter that transforms the JSON while populating the Entry Model, but I do not want to convert the JSON representation of the markup to…markup unless something needs to use that markup, so not until rendering. Maybe I can use a closure to defer rendering and still avoid direct access to the Contentful SDK.
- What if I want to import existing HTML? Should I convert it to this JSON format, store it to a plain text field, or what?
- What additional vendor-specific issues might I face working with this product now or in the future?
At the very least, Contentful could provide an option to perform the transformation on their end, before returning the Entry.
Actually, I have one other use case for retrieving a Rich Text Field, which is when that Field contains markdown rather than markup. Markdown is a standard format and is very worthwhile for the CMS users that prefer it. In this case, something needs to transform the markdown to markup. Markdown does not require vendor-specific code, use vendor-specific data formats, or require vendor-specific implementation knowledge.