You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

 

This concept captures several related improvements to the Magnolia forms/dialogs. They address various sides and pain points with the current UI framework, in order to gain flexibility, sanitize our own customizations and expose more easily the key benefits of Vaadin (ease and speed of such developments).

Most work is expected to be carried out through the following ticket/epic. This ticket, as well as linked support tickets hold several concrete scenarios.

MGNLUI-2542 - Getting issue details... STATUS

For examples of standalone prototype Vaadin applications, see:

 

1. Use cases

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)

 

2. General directions & goals

  • 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)
  • Reduce technical debt

 

3. PoC phase

  • Goals

    • Validate several assumptions from Mika

    • If all goes well, put it all together at the end, through an Integration phase

  • Process

    • To be carried out by the VN Core Team
    • Try to work in pairs (can still switch afterwards), or alternate between group phases and individual work/thinking
    • Keep each PoC standalone until the end of the PoC phase
  • Target date:
    •  

PoC #1: New FormPresenter

DEV-279 - Getting issue details... STATUS

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
      • -
  • Enable or validate one field from the value of another one
  • 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
    • -

PoC #2: Validation bubbles below field

DEV-280 - Getting issue details... STATUS

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

Default Vaadin validation is as follows:

  • warning icon
  • tooltip when hovering the field

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

PoC #3: Complex Fields refactoring

DEV-281 - Getting issue details... STATUS

Goals:

  • Get rid of Magnolia-specific components within field implementations
  • Get rid of AbstractCustomMultiField abstraction

The following three may be done independently:

—without Magnolia component/definition inside field implementations

Pure Vaadin CompositeField
  • 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?
Pure Vaadin MultiValueField
  • 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>
      • (lightbulb)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)
Pure Vaadin LinkField
  • 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

 

4. Integration phase

- To be determined

  • One "Integration PoC" of existing work
    • e.g. still as a small Vaadin application, but combining configured forms, complex fields, sub-field validation and a dynamic behavior
  • Compatibility research
    • preserve old behaviors/factories and classes to work side-by-side with the new ones 

 

 

  • No labels