What's wrong 

The issues are briefly summarised in  MGNLUI-3490 - Getting issue details... STATUS . This page aims to provide a bit more details and possible ways to improve the situation.

Localisation support

• Mess with the interfaces, high level of indirection.
  • Transformer#hasI18NSupport, TransformedProperty#hasI18NSupport which delegates to the first one.
  • Three objects' methods have to be called so that the new language is applied to a property (Transformer, TransformedProperty and DefaultI18NAuthoringSupport):
    • DefaultI18NAuthoringSupport#constructI18NPropertyName;
    • Transformer#setI18NPropertyName;
    • Transformer#setLocale which simply stores new locale in transformer object;
    • TransformedProperty#fireI18NValueChange which in reality simply re-reads the value from the transformer.
• I18NAuthoringSupport digs into UI structures code searching for the components with localize-able data-sources.
  • Logic separation levels breached - ideally Vaadin-agnostic component crawls the UI hierarchy searching for the property data-sources that can be localised;
  • Looks cryptic and patchy - one has to know how the forms are composed and how the i18n mechanism is implemented in Transformers and TransformedProperty;
  • Rigidness and hacks - instanceof's checking the abstract objects to belong to concrete types like BasicTransformer, TransformedProperty etc.
• Poor support of multi-field localisation 
  • The old property transformers do not support i18n and that probably cannot be fixed due to their implementation;
  • The new "delegating" transformers do support i18n but internally management of locale-specific data is complicated.
• MGNLUI-3491 - Getting issue details... STATUS  - switching language negatively affects validation.

Default values

• Handled only once by the FieldFactory object. Later during lifecycle of the field the default value is not resolvable.
  • Consequence - during change of locale there is no straightforward way to set the default value for a localized property ( MGNLUI-3489 - Getting issue details... STATUS ).

Read-only state

Resolved only based on the setting coming from the field definition, should there be other factor that might influence the field's read-only state - they are omitted ( MGNLUI-3448 - Getting issue details... STATUS ).

• AbstractFieldFactory#setConstraints - accesses field's property datasource to set read-only state, could be done within transformer object.
• BasicTransformer#readFromItem() sets the read-only state of the underlying item property which does not make a lot of sense (TransformedProperty backing-up the field never reads this value).

First solution attempt: "reactive" form approach

The main idea of this solution is that when major changes happen (e.g. locale switched) - the form should just be re-generated instead of trying to adapt to the changes by manually modifying the underlying structures. Along the way we try to stream-line the way the read-only state and default field values are handled.

Why this approach should work? When we re-generate the form - we only re-create the UI part and the property Transformers, the underlying data (e.g. JCRNodeAdapter) would stay modified and intact, i.e. we re-bind the newly generated fields to the same Vaadin item. That item is anyway has to fully represent the changed state of the data (required by actions such as SaveDialogAction which simply call JcrNodeAdapter#applyChanges() method).

Steps to make

Allow detail sub-app/form dialog to re-generate the form. Can be done fairly easily without major API changes:

• FormView should become clearable - i.e. all fields should be easily removed.
• FormBuilder#buildForm() once again.

Support locale

What to do (initial thoughts)

Default value/read-only state

• Since TransformedProperty delegates most of the calls to Transformer - the latter should probably aggregate most of the mentioned functionality. 
  • Transformer object could get additional methods on the interface (e.g. get/setReadonly() and get/setDefaultValue())
  • Then transformer could resolve read-only state based on additional info coming from the underlying item (i.e. would still claim it's read-only if the item it is connected to cannot be modified).
  • Transformer would also be capable of setting a default value for any property it creates.
• i18n 
  • Since we now store the current locale in the sub-app context we could re-generate the form each time the locale changes
    • underlying data wouldn't suffer since the values are propagated to datasource (e.g. JcrNodeAdapter) with Transformer;
    • DefaultI18nAuthoringSupport can be injected into transformer and be used simply to resolve the localised names of properties;
    • locale would be set for Transformer object upon form creation;
    • TransformedProperty's would be re-created.