[MGNLCT-55] Generate a select field to limit entry to a specified set of options Created: 29/Aug/18  Updated: 15/Aug/19  Resolved: 10/Apr/19

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

Type: Story Priority: Neutral
Reporter: Oanh Thai Hoang Assignee: Quach Hao Thien
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 3d 4.5h
Original Estimate: Not Specified

Issue Links:
Relates
relates to CFGUI-99 Defining a YAML list directly through... Open
relates to MGNLCT-132 Type is ignored in Select box and val... Accepted
relates to MGNLCT-127 DOC: It is possible to define a list ... Closed
causality
is causing MGNLUI-5260 multi-reference properties are broken... Closed
dependency
is depended upon by MGNLCT-118 DOC: Describe Select Box - contenttyp... Closed
supersession
supersedes MGNLCT-64 Contenttype field with limited option... Closed
Template:
Patch included:
Yes
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)
Date of First Response:
Epic Link: Content Types finalization
Sprint: Features 8
Story Points: 5

 Description   

User story:

As a Business Analyst / Developer, I want to specify a limited set of options for the value of the property and the UI will enforce that the user can only supply one of those options.

Acceptance criteria:

  • Developer can supply a set of options values
  • Developer can supply a set of option labels.
  • Developer can still specify the type as Integer, String or any other "raw type".
  • UI will show a select box control by default.
  • Developer can specify to use an alternative control (such as "radio button" group) by overriding the "class" or "fieldType" property in the app descriptor.
  • Criteria

 

Model suggestion:

model:  
- name: 'firstName'  
- name: 'category'    
  type: String 
  options:
  - value: bullet
    label: Bullet
  - value: ordered
    label: Ordered
  - value: inline
    label: Inline

Note: "label" is optional.



 Comments   
Comment by Christopher Zimmermann [ 19/Sep/18 ]

The model above does not provide a way to specify both values and labels. Both are required.

I think we should use how the select field configuration works, but remove specifying "value" fields since they are redundant with the name fields. That is - just use the name as the value.

(Labels are optional)

https://documentation.magnolia-cms.com/display/DOCS57/Select+field

          options:
            - name: bullet
              selected:true
              label: Bullet
            - name: ordered
              label: Ordered
            - name: inline
              label: Inline

Comment by Christopher Zimmermann [ 19/Sep/18 ]

In the model, I think "options" would be clearer and more descriptive than "enum".

Comment by Mikaël Geljić [ 19/Sep/18 ]

Model-wise, we're still primarily interested in the possible values; I suggest not to bother too much with that until MGNLCT-60 (because option labels would as well have to be i18n'ed with a key generator then). Meanwhile:

  • does it remain possible to use a select field i18n key for the option?
  • does the caption fall back to the value if empty and no key is provided?

Apart from that, defaultValue is part of property definitions, so no need for the selected flag here.
And lastly I would agree with options for naming.

Comment by Christopher Zimmermann [ 20/Sep/18 ]

Agree "selected" is not needed.

Comment by Simon Lutz [ 10/Jan/19 ]

Review needed.

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

Is this a UI concern leaking into the model?
—No, it may be seen as integrity metadata (based on which we may analyze, report, or help migrate data).
Later we may consider tightening it with a validator, when we add integrity validators to the model (must-have for an upcoming Management API).

UI rather declares datasources these days, should we use something similar?
—Benefit here is to be able to predict the content model, when a small set of possible values is expected (Male, Female, Non-binary, etc.).
Updating those accepted values should trigger a Content Type evolution step (eventually).
For the cases where dynamic values live outside the model, this is not an actual model constraint. A dynamic select field should be configured in the app instead.

Apart from that:

  • options sound good
  • no need for a name, we should just have value as a base
  • re: label, let's be consistent with PropertyDefinition. This one has it, although I failed to find any usage of it in AppWithContentType, nor in detailTemplate; anyhow it should be optional, and the app should use (maybe capitalized) value if not provided.
  • provided values should be convertible to the chosen type (parsed properly or add a definition problem)
Comment by Christopher Zimmermann [ 12/Feb/19 ]

OK, changing "name" to "value".  Labels are optional. We have:

          options:
            - value: bullet
              label: Bullet
            - value: ordered
              label: Ordered
            - value: inline
              label: Inline

Comment by Quach Hao Thien [ 28/Mar/19 ]

Hi czimmermann and mgeljic,

Do you think we should support all properties defined in this link or just basic properties such as name, value, label, and selected, which could be reused from SelectFieldOptionDefinition.java?

Comment by Mikaël Geljić [ 29/Mar/19 ]

Hi Thien,

In content-types, we're only interested in describing the model / data structure, not the UI behavior. Field behavior can be further customized in the app descriptor. So here it's only about the options, and we just go with value & label (optional), as in Topher's last comment. You can read all previous comments to see how we got there.

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