Dynamic forms - PoC phase

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

• locale and i18n handling
• complex fields (only text fields, selects)
• visual appearance, no MagnoliaTabSheet needed, just a plain VerticalLayout with one-to-many FormLayouts

• As GWT Extension
  • stateChange
    • errorMessage
    • + validationVisible
    • 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

• 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?
      • check out Sasha's talk from mconf16
      • Designing UIs declaratively (Vaadin docs)
      • icing on top of the cake really 

• Good
  • not bound to factory
  • move away from AbstractCustomMultiField / createLocalField
• valueChange propagated
  • exposing getFieldById/Name
• 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>
    • 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