Dynamic forms and cross-field validation

See this ticket and linked support tickets as well for concrete scenarios.

MGNLUI-2542 - Getting issue details... STATUS

We need to support such dynamic forms in a much easier way. Collecting some commons requirements:

populating select options based on the value of another field
validating a field depending on the value of another field (including within a composite field itself)
enabling/disabling fields conditionally
potentially custom handling of any field, via plain Vaadin code
updating form buttons (enabling/disabling/relabeling)

Exposing hooks on form-level
- currently only possible on field-level via FieldFactories
- fields & factories are only aware about themselves, in isolation. They're not aware about other fields and this is harder to do than it should.
Use more of Vaadin out of the box
- less customizations
- get rid of legacy Vaadin 6.x or client-side code
Open up APIs to offer more possibilities (data-binding, or dynamic/ cross-field behaviors)

Reading definitions and building tabs and fields

1 Vaadin FieldGroup + FormLayout for each tab (merge bits from FormBuilder)
Result: a simple Vaadin application (w/ ui-framework on the classpath)
- Mika might prepare the skeleton on a branch
FormPresenter invoking FieldFactories
- for the PoC, you can instantiate factories manually
- either refactor existing ones, or reimplement a simple TextFieldFactory with less Magnolia dependencies
  - maybe API like public Field<T> createField(D definition)
  - so we can reuse a single FieldFactory to produce multiple instances of a field
- FieldFactories no longer doing property data-binding (#setPropertyDataSource)
  - FormPresenter doing the databinding instead => fieldGroup#setItemDataSource
  - -
Not needed for the PoC:
- locale and i18n handling
- complex fields (only text fields, selects)
- visual appearance, no MagnoliaTabSheet needed, just a plain VerticalLayout with one-to-many FormLayouts
- -

Validation as a Vaadin JS Extension, see the few links below:

Integrating JavaScript Components and Extensions (Vaadin docs)
class com.vaadin.server.AbstractJavaScriptExtension
Component Extensions & Component and UI Extensions (the GWT way, Vaadin docs)
see also TextAreaStretcher, Bidi (GWT way) or JCrop, RowScroller (JS way) for more extension examples

Default Vaadin validation is as follows:

Extension should primarily add the bubble below

Same styles as now
- see
- bubble width is the same as field width with border
- arrow tip should be around 30–40px from the left
Result: small Vaadin application
- Apply to a TextField (e.g. using standard Vaadin email validator)
- If using the Magnolia theme, then field border should become red too
Currently tooltip is hidden via CSS in Magnolia
- we can still do this the same way, maybe as well for the warning icon

Goals:

The following three may be done independently:

—without Magnolia component/definition inside field implementations

close to AccessControlField
Except fields are not hard-coded
- pass sub-fields into constructor?
  - maybe as map with field-names as keys?
- would help us keeping FieldFactories outside of field implementations
  - i.e. get rid of infamous AbstractCustomMultiField#createLocalField
also bind fields internally via FieldGroup?
reuse #setValidationVisible and handling of valueChange on sub-fields
Result: simple Vaadin application
- operating over a PropertysetItem or BeanItem
- part 1. using a CompositeField for First name and Last name
  - laid out horizontally
  - has an API to set direction (minimum requirement)
- part2. also API to set an arbitrary layout
  - if feasible, but not a must-have
  - or maybe using a Vaadin declarative layout?
    - check out Sasha's talk from mconf16
    - Designing UIs declaratively (Vaadin docs)
    - icing on top of the cake really

close to AccessControlListField
reuse some form of EntryFieldFactory (maybe also NewEntryHandler if applicable)
Result: simple Vaadin application
- operating over a PropertysetItem or BeanItem
  - i.e. extends CustomField<I extends Item>
  - or extends CustomField<C extends Collection> (maybe more in line with Vaadin 8?)
- with a property of type Collection or List, then one entry per entry in the collection
- field needs to create Vaadin properties for each entry in the list, and bind it internally to sub-fields
- also bind fields internally via FieldGroup?
- reuse validation and valueChange logic from AccessControlListField
- steps:
  1. a MultiField of TextFields (can be hard-coded)
  2. a MultiField of a CustomField type (First name + Last name)
  3. a MultiField with the pluggable NewEntryHandler (closer to use cases in Magnolia where subfields are configured)

Inspired from AccessControlField$PathChooserHandler
Result: small Vaadin application
- see info.magnolia.dev.acls.AccessControlFieldUI in Mika's sandbox
- opens a Vaadin Window
  - field inside the window shares property data-source with text field

Page tree