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
andTransformedProperty
; - Rigidness and hacks
- instanceof
's checking the abstract objects to belong to concrete types likeBasicTransformer
,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.
Use authoring locale when generating fields. Since we now track the current authoring locale at least in SubAppContext
(would probably make sense to propagate it to whole UIContext
) - that is also not hard to implement:
- Inject
SubAppContext/UiContext
intoFieldFactories
, set authoring locale to property transformers and fields themselves.
Refactor transformers and TransformedProperty
. The most sensitive part (esp. with multi/composite transformers):
Transfomers
should now assume they work with just one locale - no need to be able to track several locales all at once.- Simplify i18n support:
BasicTransformer#i18NPropertyName
becomes unnecessary - we don't need to set it externally, we can injectI18NAuthroingSupport
and generate i18n-aware property name via it internally.TransformedProperty
's i18n-related methods (hasI18NSupport
andfireI18nValueChange
) become also redundant sinceTransformedProperties
will be regenerated.For read-only state support: add read-only state setter/getter to
Transformer
interface and makeTransformedProperty
delegate to it:@Override
public boolean isReadOnly() {
return super.isReadOnly() && transformer.isReadOnly();
}
What to do (initial thoughts)
Default value/read-only state
- Since
TransformedProperty
delegates most of the calls toTransformer
- the latter should probably aggregate most of the mentioned functionality.Transformer
object could get additional methods on the interface (e.g.get/setReadonly()
andget/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
) withTransformer;
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.
- underlying data wouldn't suffer since the values are propagated to datasource (e.g.
- Since we now store the current locale in the sub-app context we could re-generate the form each time the locale changes