You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.

I18n

  • 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 
    • instanceof's checking the abstract objects to belong to concrete types like BasicTransformer, TransformedProperty etc
  • Not possible to localize the multi-fields.
  • 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 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

 

  • No labels