Page tree
Skip to end of metadata
Go to start of metadata


In order to validate assumptions for cleaner usage of Vaadin in Magnolia forms, 3 PoCs were conducted in September 2016. This page archives their requirements and debrief notes.


PoC Goals

  • Validate several assumptions from Mika

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


  • 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:

General directions & goals were that of the refactoring initiative—see parent page.

Deliverables: PoCs took the shape of several, independent Vaadin "sandbox" applications, alike e.g.:

General outcome: (tick) Confirmation

  • much less custom code, more Vaanilla Vaadin => help reduce technical debt
  • e.g. FieldGroups, JS Extensions, declarative layouts
  • more Vaadin expertise


PoC #1: New FormPresenter

DEV-279 - Getting issue details... STATUS

Expectations Outcome
  • Reading definitions and building tabs and fields
    • Result: a simple Vaadin application (w/ ui-framework on the classpath)
  • 1 Vaadin FieldGroup + FormLayout for each tab (merge bits from FormBuilder)
  • 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
  • APIs
    • stateless FieldFactory
    • stateless FormPresenter
    • defs and items passed via #start
  • Plain Vaadin
  • (y)
Enable or validate one field from the value of another one(error) 
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

Next steps

  • Extensibility
    • Interface over Abstractions
    • Public over Protected (extending should be demoted)
    • (lightbulb) Generate wrapper implementations for component interfaces
  • Backwards compatibility


PoC #2: Validation bubbles below field

DEV-280 - Getting issue details... STATUS

Expectations Outcome

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
  • As GWT Extension
    • stateChange
      • errorMessage
      • + validationVisible
      • (question) triangle
    • Test drive validation on a CompositeField
    • pluggable to any Vaadin form, not just Magnolia
    • (y)
  • As JavaScript Component
    • vs. JavaScript Extension
    • addComponent?
    • JS Connector + HTML template (y)
    • valueChange server-side
    • moving away from GWT

Next steps

  • Combine the two approaches
  • Additional style enhancements / animations


PoC #3: Complex Fields refactoring

DEV-281 - Getting issue details... STATUS

Expectations Outcome
  • Get rid of Magnolia-specific components & defs inside field implementations
  • Get rid of AbstractCustomMultiField abstraction
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?
  • Good
    • not bound to factory
    • move away from AbstractCustomMultiField / createLocalField
  • valueChange propagated
    • (question) exposing getFieldById/Name
  • (question) BeanItem multifield APIs
    • need more conventions?
  • Declarative-layout based composite field (y)
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 in Mika's sandbox
    • opens a Vaadin Window
      • field inside the window shares property data-source with text field

Next steps

  • do some dynamic relationship on form level
  • refine generic value typing for complex fields
    • ideally move away from Items, in favor of domain types
    • Challenging with JCR adapters in particular




  • No labels