Page History
...
The issues are briefly summarised in
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
...
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
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 Default value/ read-only state
...
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.
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();
}Delegating transformers should adapt to one locale case:
- i.e.
DelegatingMultiValueFieldTransformer#items
which tracks separate items for all locales - should be replaced with a single item for the current locale. - TBD: research and prove with PoC.
- i.e.
Other consequences:
DefaultI18NAuthoringSupport#i18nize()
wouldn't be needed any longer - all the ugliness could go away.- Default values and read-only states would be much better and logically respected during locale changes since
FieldFactories
would re-apply those on form re-generation.
Effort source:
https://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=shortlog;h=refs/heads/refactor/MGNLUI-3490
...