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
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.
- currently only possible on field-level via
- 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
The PoC phase was conducted in September–October 2016. Refer to child-page Dynamic forms - PoC phase for details and outcome.
4. Productization phase
Based on the PoC results, we first collected the following tasks, in order to bring new forms on par with the current Magnolia forms.
F1. Formalize new Form APIs & Assess Configuration changes
DEV-419 - Getting issue details... STATUS
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 towards a separation between bindings and layout
- Envision repackaging
- Draft eventual backward compatibility
- 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)
- ideally move away from Items, in favor of domain types, e.g. CompositeField<Contact>
- Challenging with JCR adapters in particular
- MultivalueFields would in turn be typed with Collection types (List, Set, ordered/unordered, etc.)
- Adapt new default CompositeField & MultivalueField
F3. [TOFILE] Reimplement Tabsheet customizations, ideally 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
- 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 )
F8. [TOFILE] Reimplement the error count banner at the top of the form
- again, maybe as Form component extension?)
- + jump to next error
- Think page objects
- 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:
- Valo-based theme switch
- Generate concrete FieldDefinitions (& builders) from our interfaces
- Plain Java Decorators (add/remove field by user-based form decorator)
- supplanting blossom
- Documentation generation (via pegdown)