[MGNLCT-28] Complex fields - switchable groups Created: 16/Apr/18 Updated: 25/Mar/22 |
|
| Status: | Open |
| Project: | Content Types |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | blocked | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 4d 4.5h | ||
| Original Estimate: | Not Specified | ||
| 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 phase 2 |
| Description |
|
User story:
Acceptance criteria:
Notes: Consider that this feature might not need to be part of the data model for the content type - it could be handled purely related to the presentation of the editing form. |
| Comments |
| Comment by Mikaël Geljić [ 23/Aug/18 ] |
|
First review feedback:
Food for thought: model:
- name: 'firstName'
# - name: 'link'
# type: text:String|date:Date|enabled:Boolean
# type: optionalGroup
options:
- name: 'externalLink'
- name: 'internalLink'
type: Page
- name: 'externalLink'
optionalGroup: link
- name: 'internalLink'
optionalGroup: link
type: Page
Resulting structure doesn't distinguish regular properties from switchable/optional ones (every prop is optional by default) myTestNode/ + firstName = mika + link = internalLink + internalLink = cafebabe-cafe-babe-cafe-... having a flat listing of properties could be convenient for a CTDelivery endpoint if we were modeling a RDB table, we would add columns for internalLink, externalLink, with different types To be discussed/debated further (also competitor notes focused on that could help) |
| Comment by Christopher Zimmermann [ 29/Aug/18 ] |
|
Yes, there should be one property which a developer can read to determine which "switch option" the author has selected. And yes, we need fixed names (and a fixed type) for each property, so that the content is predicatable and easy to work with as a frontend developer / templater / or other "content consumer". (The example usecase is the stories app where an author can choose what type of "lead image" to use for a story. Based on that different fields are displayed to the author.
|