Page History
...
- An item provider only needs to know how to access the data. In contrast, the transformers in the 5 UI framework were responsible for both types of data operations – reading and writing. In Magnolia 6 UI, data updates should be piped into back-end items via simple fields by means of Vaadin 8 data binding (Binder objects).
- Unlike transformers, item providers do not have to deal with the deprecated Vaadin 7 Item API and do not require manual verifications that child properties are populated within an item.
- Item providers have a clearer concept of chaining. They get a reference of an item from a previous level in the hierarchy, making the whole complex data binding process recursive.
- The number of provider types is much lower in Magnolia 6 UI, compared to a relatively high number of field transformers in the 5 UI.
- There's also provider implementations that can handle JSON structures, task and notifications items, assets or specific product content items.
Where
...
they can be used
Item providers can be used in:
...
| $type | class and description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
jcrChildNodeProvider |
Resolves a JCR child node from the parent. Suitable for sub-forms only since it relies on a parent.
| ||||||||
jcrGetIndexedChildNode |
Resolves an indexed JCR child node from the parent. Suitable for sub-forms only since it relies on a parent. | ||||||||
|
Proposes a JCR node property as an item datasource. Typically used in complex fields with sub-editors where a single field entry needs to be exposed as an editor.
| ||||||||
jcrNodeFromLocationProvider |
Resolves JCR node content from the current location. |
...
Overview
Content Tools