Page History

...

• 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
  • Looks cryptic 
  • - 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
  Not possible to localize the multi-fields
  • .
• 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.

• Jira
  server Magnolia - Issue tracker serverId 500b06a6-e204-3125-b989-2d75b973d05f key MGNLUI-3491

   - switching language negatively affects validation.

...

• 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 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 locale would be set for Transformer object upon form creation;
    • TransformedProperty's would be re-created.