[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:

As a Business Analyst / Developer, I want to define a switch control, and a switchable set of groups, so that I can model my input requirements better, and provide a better author experience.

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:

  • usage of subnode transformer on the switchable one has no effect? (doesn't actually create sub-node)
  • invert w/ composite fields?
  • generated names for switchable entries
  • ideally we need fixed names (e.g. in template, if switchable = externalLink, then look for externalLink property)

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
getCT().getModel()... => get list of possible property names

if we were modeling a RDB table, we would add columns for internalLink, externalLink, with different types
switchable part is a UI concern; there cannot be a required property in a switchable group

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.
For example a property "visualType" which could have the values "embed", "video", or "image".

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".
For example a property "embedsource".

(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.
See: https://demo.magnolia-cms.com/.magnolia/admincentral#app:stories:editor;/stories-demo/lost-and-found-in-swiss-alps:edit)

 

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