[MGNLUI-3772] Support BeanItems with enum members Created: 15/Feb/16  Updated: 09/Feb/17  Resolved: 12/Aug/16

Status: Closed
Project: Magnolia UI
Component/s: forms
Affects Version/s: None
Fix Version/s: 5.4.9, 5.5

Type: Improvement Priority: Neutral
Reporter: Mikaël Geljić Assignee: Mikaël Geljić
Resolution: Fixed Votes: 0
Labels: BeanItem, smallapp, vaadin
Remaining Estimate: 0d
Time Spent: 3.5h
Original Estimate: 3.5h

Issue Links:
causality
dependency
depends upon MAGNOLIA-6747 Export EnumCaseInsensitive from node2... Closed
is depended upon by MGNLUI-3731 Migrate legacy permissions app to sec... 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)
Release notes required:
Yes
Date of First Response:
Epic Link: Phase out Admin-interface Legacy
Sprint: Saigon 56
Story Points: 8

 Description   

Many small apps use our form framework (vs. plain Vaadin forms) to build forms from configuration, and benefit from validation styles.

It is then possible to use the form framework with Vaadin BeanItems, for example.

However, it is not possible to "bind" an OptionGroup field to an enum member of a BeanItem. Several reasons for that:

  • Transformers are initialized anyway, and try to #setValue on the underlying property (e.g. MethodProperty), with potential incompatible types.
    • Transformers actually make very little sense for BeanItems, that would be super convoluted
  • OptionGroup will want to use a String for value presentation anyway, so we need a Converter
    • We can set a converterClass already, though Vaadin's StringToEnumConverter is a no-go, since it humanizes and localizes the presentation already (we use a different caption mode)
    • Instead, we need a simple/stupid converter from the enum to its name(), and back, and we do need that String here, because the option values come from config.
  • Finally, default value doesn't work when value and property types are incompatible—even when a converterClass is configured
    • there we can add a fallback to tentatively solve that

If for some reason we don't want to do any of the above, one has to resort in using booleans or Strings in BeanItems, which is simply less elegant.

Finally, if our form-framework were more elegant (e.g. wrapping plain Vaadin forms, or not self-imposing itself just for the sake of validation bubbles), this would surely be a lot more trivial: such binding takes less than 5 minutes to do with plain Vaadin.



 Comments   
Comment by Mikaël Geljić [ 15/Aug/16 ]

For release notes:

Enhancements for Field Factories:

  • Improve support of Vaadin BeanItems in configured forms (skip transformers)
  • Setting a converterClass now also applies to default values
    • Additionally, converter is only set if the field does not support the model type
  • Field factories may customize retrieval of default value from config, via #getConfiguredDefaultValue
  • Field definition type may be set as a fully-qualified enum name
  • Rename SelectFieldFactory's #getSelectFieldOptionDefinition into #getOptions
Comment by Evzen Fochr [ 15/Nov/16 ]

What i rly hate is this part

Enhancements for Field Factories:
Improve support of Vaadin BeanItems in configured forms (skip transformers)

because of it, product detail subapp in commercetools is broken. It used tranformers to pick correct text from LocalizedString class served by CommercetoolsProductItem (which is BeanItem child)

Comment by Mikaël Geljić [ 15/Nov/16 ]

Transformers are a JCR-specific facility for mapping node-structures to field implementations.
In the case of BeanItems and/or custom save actions, you have all the Vaadin freedom you need in the first place; subclassing BeanItem is an arguable choice as well.
Either way, if you need advice to do it right, we're glad to help

Comment by Evzen Fochr [ 15/Nov/16 ]

Subclassing BeanItems should help in my case, but I dont know how would i solve displaying f.e. MonetaryAmount in 2 different ways in same form (once currency first and on other place currency last).

Comment by Mikaël Geljić [ 15/Nov/16 ]

Converters are most likely the answer to that one; as far as I see, it's also independent from those localized-strings. Let's arrange a session/call, comments on a closed ticket are a bit limited . Meanwhile I might check out the repo.

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