Page History

...

Reasons to bother What changes Outcome

Form definition is nailed to the concept of the tabs
- presentation definition is entangled with the model

FormDefinition separates field/property definitions from the layout definition

Tabbed layout becomes just a concrete case of the layout definition
We provide other types of layouting possibilities - HTML/Vaadin declarative layout/Custom Component

Possibly we introduce an alternative term 'editor' which is more generic than the form

Benefits

More flexibility
Possibility to define complex fields with the same definitions that we use for the forms
- i.e. complex fields also become forms

Questions

How to provide compatibility between the current form definitions and the new ones?
- Resolve on programmatic level, i.e. allow special definitions that take the old one and then the app/dialog transforms them into the new ones?

Solution proposal

One Binder per Locale, one layout per Locale
Non i18n properties share the same Binder (typically the one for the default language configured in Magnolia)
Layouts are created eagerly and are simply switched when changing language in the UI. Memory consumption should be no issue, cause usually configured languages are just a few - we cache the layouts anyway and don't need to recreate them upon every language switch
Current implementation at https://git.magnolia-cms.com/users/apchelintcev/repos/ui-framework-vaadin8/commits/5493abd438dd257cbb47ea57df6a6d9287ee605f (needs https://git.magnolia-cms.com/users/apchelintcev/repos/main/commits/b071e67ae64e4bf0199478e610e834df20777568 in order to fix an issue with LazyNodeWrapper or multi-forms will be saved only if the parent node has pending changes too)

Here's an example of how data are stored in JCR

Image Removed

and the UI part

Image Removed

Page tree