[MGNLUI-7081] Provide the appropriate context for complex attributes in FieldLayoutComponent Created: 01/Apr/22  Updated: 19/Jul/22  Resolved: 15/Jul/22

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Neutral
Reporter: Jesus Alonso Assignee: Sang Ngo Huu
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 1.5d
Original Estimate: Not Specified

Attachments: PNG File image (12).png     PNG File image.png    
Issue Links:
dependency
is depended upon by LIVECOPY-159 Fields under composite/switchable/mul... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Epic Link: Maintenance of vaadin8 framework
Team: Nucleus

 Description   

The current FieldLayoutComponent interface mainly provides this method:

void init(EditorPropertyDefinition var1, Component var2); 

This allows to the implementation class to know the affected property. Moreover, through valueContext.get it is also possible to know the main component. For instance, in this example:

form:
  properties:
    name:
      label: name
      $type: textField
    multi:
      label: multi
      i18n: true
      $type: jcrMultiField
      itemProvider:
        $type: currentItemProvider
      field:
        $type: compositeField
        properties:
          uno:
            label: uno
            $type: textField
          dos:
            label: dos
            i18n: true
            $type: textField
          tres:
            label: tres
            $type: textField 

a component implementing FieldLayoutComponent (e.g. ProtectFieldButton) will be created for the following properties: name, multi. Moreover, for each row created in the multi component, a new component will be created for the properties: uno, dos and tres. So if in multi we have 2 rows, 8 components will be created.

Unfortunately, the UI framework has a limitation so it is not possible to know the real node for complex attributes. For instance, for the previous component, we could have in JCR:

Then, when the component is created for uno property, it is not possible to know whether it belongs to multi0 or multi1. This limitation prevents implementing LIVECOPY-159.

We would need some way to link the created component with the real node the property belongs to.



 Comments   
Comment by David Lopez [ 15/Jul/22 ]

As per last statement not in the radar to do.

Comment by Roman Kovařík [ 19/Jul/22 ]

This ticket was closed as Won't do:

  • in the old (vaadin7) UI framework, the item which is bound to the field is available already at the time of construction of the field
  • the new (vaadin8) UI framework is (by design) not directly aware of underlying data so
    • you can use the same fields in different APP with different king of data
    • UI and data levels are decoupled and can be developed separately
    • valueContext can be used to retrieve the root items for simple fields but this is not possible in multi/ complex fields
      • we interacts with UI (add/remove/order) 
      • as data are created/removed later when clicking the save button
Generated at Mon Feb 12 09:42:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.