[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: |
|
||||||||
| 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 |
Acceptance Criteria:
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. 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. |