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).
What to do
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