[MGNLCT-63] RichText type for contenttypes Created: 10/Sep/18  Updated: 18/Apr/19  Resolved: 27/Mar/19

Status: Closed
Project: Content Types
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1

Type: Improvement Priority: Major
Reporter: Christopher Zimmermann Assignee: Sang Ngo Huu
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0d
Time Spent: 1d 7h
Original Estimate: 2d

Issue Links:
dependency
is depended upon by MGNLCT-99 DOC: RichText type for contenttypes Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Content Types finalization
Sprint: Features 7
Story Points: 5

 Description   

As a developer I want to easily use RichText properties in my content-type based apps, so that I can provide the apps that my projects and customers require.

Acceptance Criteria:

  • I can easily supply a RichText input field without needing to supply extra configuration in the app definition file or decoration

Rationale:

This is different then the existing "String" type because the data-type is fundamentally different than raw text (it stores HTML) and a developer retrieving the content must handle it so differently, and because where it is used is so different than a plain string of english - that it should be considered a completely different type. (As most (all?) of the other CMS does.) 

 



 Comments   
Comment by Simon Lutz [ 10/Jan/19 ]

Review needed.

Comment by Sang Ngo Huu [ 11/Jan/19 ]

To me, model in content type just a define the format/structure of data. We're trying to put many things to adapt with current apps structure. But let think about the case I'm using REST API, I don't care about the richtext field, select field, I just care about the type of data.

If we still want to have richtext field for content type, mgeljic has an idea: define new type: html

Comment by Christopher Zimmermann [ 14/Jan/19 ]

sang.ngo OK, I hear what you are saying. 

I still think it is more useful to have a property called "rich text" than "html". It's true that it's coming from the requirement to create entry forms with RichText fields, but I think its also valid to think of a "rich text" property from a content modelling perspective. 

If we think of developers looking at a content type definition "rich text" clearly evokes a text with some links, bold, h1, list etc. Whereas an "html" field evokes ANY html including snippets for widgets, JS, CSS extra.

So even if the rendering in a template (after REST, or directly in Magnolia) would be identical, the type of content is quite different. And actually I guess the rendering would be different too because for a "rich text" you would sanitize it to remove any Javascript, but for an "html" you would typically allow the JS to run. (Most common use of "html" in templating is as a "backdoor" to allow marketing teams to do anything. (Not a best practice of course, but often done in real projects.))

Another reason that I favor "rich text" is that is how all of our CMS competitors provide in their "content models".

https://wiki.magnolia-cms.com/display/TH2/Competitor+Research+-+Content+types

Some of our competitors use controls instead of properties - but even those that do use properties like "boolean" (contentful, contentstack) , still use "rich text".

Or I also see "formatted text" (hippo), which would also work for me.

To summarize, I think "richText" (or maybe "formattedText") would be better for project developers than "html" as a property type. 

WDYT? Do you see using "richText" as a property type causing problems?

 

Comment by Mikaël Geljić [ 28/Jan/19 ]

No need for much nit-picking, let's just go with this; I concur with you Topher: rich text does convey minor model info.
Beyond field generation, this may be used for specific transformation according to media type, sanitizing (upon serving) or rendering (upon consuming).

Re: case, I recommend upper camel case (i.e. String, Date, RichText, Address) as a convention for built-in types and sub-models (it helps them stand out); Of course it should be case insensitive though.

Generated at Mon Feb 12 00:36:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.