[MGNLUI-3473] Provide additional transformers alike the MultiValueSubChildrenNodeTransformer and MultiValueSubChildNodeTransformer for "multiselect fields" Created: 25/Jun/15  Updated: 03/Aug/15  Resolved: 23/Jul/15

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

Type: Improvement Priority: Neutral
Reporter: Christian Ringele Assignee: Christoph Meier
Resolution: Won't Fix Votes: 0
Labels: support
Remaining Estimate: 2d
Time Spent: 1d
Original Estimate: 3d

Attachments: PNG File ListToSetTransformer-data-structure.png     PNG File MultiValueSubChildNodeTransformer-data-structure.png     PNG File MultiValueSubChildrenNodeTransformer-data-structure.png    
Issue Links:
causality
duplicate
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)
Date of First Response:
Sprint: Sprint 2 (Vietnam)
Story Points: 8

 Description   

The TwinColumnField (actually a ComboBox) stores the data by default into a JCR MultiValue property.
Same as the as the MultiField does by default.

There is also the need for TwinColumnField to have this data stored different, into sub nodes etc as the DelegatingMultiValueFieldTransformer and DelegatingMultiValueSubnodeTransformer for the MultiField does.

But the two Tramsformers DelegatingMultiValueFieldTransformer and DelegatingMultiValueSubnodeTransformer of the MultiField won't work for the TwinColumnField:

Caused by: com.vaadin.data.util.converter.Converter$ConversionException: Unable to convert value of type com.vaadin.data.util.PropertysetItem to presentation type interface java.util.Set. No converter is set and the types are not compatible.

Finally triggered, by a Type missmatch as the MultiField operates on Type PropertysetItem and the TwinColumn on a Set (LinkedHashSet in the end), in:
com.vaadin.ui.AbstractField.setPropertyDataSource(Property) line 623

setConverter(newDataSource.getType());

Creating a custom Transform for this is not an easy task, the customer gave up because its too time intensive.
He switcher to a custom SelectField using MultiValues. But the TwinCol would have matched perfect his use case (a very long list to choose from).



 Comments   
Comment by Christoph Meier [ 22/Jul/15 ]

See screenshots for the data structures we want to achieve with the new transformers.

  1. ListToSetTransformer => the default transformer of the TwinColSelectField
  2. MultiValueSubChildNodeTransformer-data-structure
  3. MultiValueSubChildrenNodeTransformer-data-structure

for (2) and (3) we need new transformers.

Comment by Christoph Meier [ 23/Jul/15 ]

See latest comment.

Comment by Christian Ringele [ 23/Jul/15 ]

Implementing a custom transformer makes sense for a specific use case where the exact wanted data structure is known.

It is know, the same as we provide it for the MultiValue field. So its no custom transformer needed. Just one that can do the same as we already provide.

Since the related support ticket (SUPPORT-4740) has been closed - it is not really reasonable to "build stocks" of such transformers.

So if the customer would not be nice and have his ticket because he (and support) gave up after time loss, then it would have more relevance?
So if he would not accept the much less good solution then its not building them on stock.
All others we provide are there, because a customer or we had a need for them and we saw the general use case.

MultiValue field saves per default a mutli value property
TwinColumn field saves per default a mutli value property

MultiValue field provides transformers for saving into a series of properties or sub nodes.
TwinColumn field provides nothing...
Even both save the same default.

Saying that the MultiVaule field needs them, and we provide them, but on the TwinColumn it would be "creating them on stocks" becuase its a "Custom" case is strange.

We provide two MultiValue fields, one can save different, the other not, why?
How to explain to a customer (which wouldn't close his support ticket).

Generated at Mon Feb 12 09:06:58 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.