Page History

• Validate a high-level architecture with clear component responsibilities
  • expose 1. field creation, 2. data-binding, 3. layouting
  • produce architecture diagrams
• Assess definition changes to support new ways of configuring forms
  • especially moving especially moving towards a separation between bindings and layout
• Envision repackaging
• Draft eventual backward compatibility (dedicated ticket for that)
• Iterate from Sang's PoC
• Keep in mind / draft check if form is dirty or not

F2. [TOFILE] Define the generic typing for complex fields (or leave it open)

• Provide validation out of the box (upon #submit)
• Provide approach for default binding & saving of JCR items (not in the centralized Form, either extended or delegated)

• sort out the problem with marking component visible / invisible in JavaScript extensions
• Safest bet => Roll back to a GWT-based AbstractExtension where we have more power
  • mostly to listen to the target component state changes
• use plain Vaadin validation state ( state.errorMessage && state.hideErrors )

• Finalize pure-Vaadin implementation of Oanh's PoC.
• From the Vaadin data-binding perspective:
  • Refine generic-typing or leave it open: move away from Items
  ideally move away from Items
  • , in favor of domain types, e.g. CompositeField<Contact>
  • Challenging with Magnolia "loose types"
  • Challenging with JCR adapters in particular
• No Magnolia definition into the field instance, use Vaadin Orientation enum for layout direction.

• Finalize pure-Vaadin implementation of Oanh's PoC.
• From the Vaadin data-binding perspective:
  • Refine generic-typing or leave it open: MultivalueFields would in turn be typed
  with Collection types
  • with Collection types (List, Set, ordered/unordered, etc.)
• Adapt new default CompositeField & MultivalueField

F3. [TOFILE] Reimplement Tabsheet customizations, ideally as Vaadin extension

• • Challenging with JCR adapters in particular
  • Should support one level of nesting of arbitrary fields, including CompositeFields
• No Magnolia definition into the field instance.
• Externalize new item handlers, in line with AccessControlListField

• Show all tabs as Vaadin Extension
• Focus first field
• Show all tabs
• Port the styling—quickly estimate effort against restart from Valo

F4. [TOFILE] Reimplement i18n support within new Form

• Generalize "variation" switching
• aka item datasource decoration somehow
• so we can support p13n variant-switching similarly

F5. [TOFILE] Refine support for backward compatibility

• Focus first field, via plain Vaadin SelectedTabChangeListener?

• a. binding strategies would cater to backward compatibility with transformers?
• b. high-level switch to use fully old dialogs / transformers / FormBuilder.... vs. new APIs

F6. [TOFILE] Reimplement the Dialog integration and/or DetailSubApp

• Reuse and style Vaadin Windows instead?
• How about dynamic resizing of dialog height?

F7. [TOFILE] Validation bubbles as JavaScriptExtension

• sort out the problem with marking component visible / invisible
• use plain Vaadin validation state ( state.errorMessage && state.hideErrors )

• How to treat form actions (commit) vs. dialog actions (close/cancel)

• again, maybe as Form component extension?)
• + jump to next error

• Generalize "variation" switching
• aka item datasource decoration somehow
• so we can support p13n variant-switching similarly

F5. [TOFILE] Refine support for backward compatibility

• a. binding strategies would cater to backward compatibility with transformers?
• b. high-level switch to use fully old dialogs / transformers / FormBuilder.... vs. new APIs

F9. [TOFILE] Reimplement help-text bubbles the same way as validation bubbles

F11. [TOFILE] Write UI tests for our 5 user scenarios

• Can only be done once the basic stones are in place
• Prove form-level agility (binding upon field(s) constructed)

F12. [TOFILE] Proof-test new APIs against Vaadin 8

• Ideally, only the data-binding "part" should be affected, not field creation nor layouting

TODO:

•  File in JIRA / MGNLUI
•  Estimate
•  Flesh out, break out into even smaller tasks
•  Add relative task dependencies

Then reevaluate progress after 2–3w.

Unprocessed ideas

•  binding strategies: default, transformerDelegate...
•  expose layouting (default from fieldDef + tabs, declarative, or other new mechanism?, responsive forms?)
•  save actions bundled in Form itself by default, can be delegated to configured action(s)
  
  • does validate ootb
•  extensibility: generate wrapper implementations for component interfaces

Related wishful improvements

—i.e. keep out as long as we can / later scope: