Page History

...

The concept of Item providers is an abstraction aiming to give developers a flexible way to specify specify which item a form field (simple or complex) should bind to and how the an item schould should be accessed. 

...

Item providers allow you to bind form views to complex nested

...

data structures and to fine tune such

...

bindings. For example, if a form binds a contact address as a separate sub-form (

...

a composite field in the Magnolia 5 UI context), the Magnolia user might want to

...

:

• Use a contact's child node to store the data

...

• , in which case an item provider that resolves a sub-node can be used

...

• .
• Store the properties directly on the contact node

...

• and keep it flat (self-reference item provider use case).

item providers get reference items as context. I.e. an address editor from the example upon data binding will get the root contact node so that it would be trivial to resolve the corresponding sub-node if needed. Forms are always populated and persisted from top of the hierarchy to the bottom.

• Item providers kick in the form lifecycle only twice (typically): when the data is fetched from the backend (to populate the form) and when the updated data needs to be flushed from the Vaadin components back to the backend (on form commit).
• item providers yield items wrapped into Optional container, so it is fine not to return anything from the item provider implementation (in such case though, the form data may not be populated or saved back to the backend).

Main advantages

Item providers represent a much simpler solution than the 5 UI field transformers.

...