PoC Goals
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: 25 Sep 2016 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.:
Vaadin + Magnolia sandbox , based on 5.5Pure Vaadin Sandbox (without Magnolia)General outcome: Confirmation
much less custom code, more Vaanilla Vaadin => help reduce technical debt e.g. FieldGroups, JS Extensions, declarative layouts more Vaadin expertise
DEV-279
-
Getting issue details...
STATUS
Expectations Outcome Reading definitions and building tabs and fieldsResult: 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 dependenciesmaybe 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
APIsstateless FieldFactory stateless FormPresenter defs and items passed via #start Plain Vaadin :y: 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
ExtensibilityInterface over Abstractions Public over Protected (extending should be demoted) Generate wrapper implementations for component interfaces Backwards compatibility
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 nowsee bubble width is the same as field width with border arrow tip should be around 30–40px from the left Result: small Vaadin applicationApply 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 Magnoliawe can still do this the same way, maybe as well for the warning icon As GWT ExtensionstateChangeerrorMessage + validationVisible triangle Test drive validation on a CompositeField pluggable to any Vaadin form, not just Magnolia :y: As JavaScript Componentvs. JavaScript Extension addComponent? JS Connector + HTML template :y: valueChange server-side moving away from GWT
Combine the two approaches Additional style enhancements / animations
DEV-281
-
Getting issue details...
STATUS
Expectations Outcome Get rid of Magnolia-specific components & defs inside field implementations Get rid of AbstractCustomMultiField abstraction close to AccessControlField
Except fields are not hard-codedpass sub-fields into constructor?maybe as map with field-names as keys? would help us keeping FieldFactories outside of field implementationsi.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 applicationoperating over a PropertysetItem
or BeanItem
part 1. using a CompositeField for First name and Last namelaid out horizontally has an API to set direction (minimum requirement) part2. also API to set an arbitrary layoutif feasible, but not a must-have or maybe using a Vaadin declarative layout? Goodnot bound to factory move away from AbstractCustomMultiField / createLocalField valueChange propagated exposing getFieldById/Name BeanItem multifield APIsDeclarative-layout based composite field :y: close to AccessControlListField
reuse some form of EntryFieldFactory
(maybe also NewEntryHandler if applicable) Result: simple Vaadin applicationoperating 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:a MultiField of TextFields (can be hard-coded) a MultiField of a CustomField type (First name + Last name) a MultiField with the pluggable NewEntryHandler (closer to use cases in Magnolia where subfields are configured) Inspired from AccessControlField$PathChooserHandler
Result: small Vaadin applicationsee info.magnolia.dev.acls.AccessControlFieldUI
in Mika's sandbox opens a Vaadin Windowfield inside the window shares property data-source with text field
do some dynamic relationship on form level refine generic value typing for complex fieldsideally move away from Items, in favor of domain types Challenging with JCR adapters in particular