Page History

...

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 a 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 (. This would represent a self-reference item provider use case).

Item providers get reference items as context. Applied to the contact address example, an address editor will get the root contact node so that it would be trivial to resolve the corresponding sub-node, if needed.

...

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

• Now, an 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 the 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 are they used

Currently, item Item providers can be used in the following two use cases:

• Item provider definition in a detail subapp. 
• Item provider definition In a form containing composite and complex fields.   In this use, the provider replaces the former field transformer functionality that is part of the UI framework 5, but no longer part of the Magnolia 6 UI.

...

The jcrCurrentNodeProvider and jcrChildNodeProvider are only suitable for sub forms only since a dependency on a parent node is presupposed to exist.

...

Examples

In a sub app definition

The jcrNodeFromLocationProvider is used for example in the Pages app (see line 7 below). This provider resolves a JCR node from its location context:

...

(A snippet of an existing full definition, see https://git.magnolia-cms.com/projects/MODULES/repos/pages/browse/magnolia-pages-app/src/main/resources/pages-app/apps/pages-app.yaml.)

An Using item provider providers is not limited only to operations related to JCR content. See the following definition, where content items are provided from a JSON structure through the use of the the jsonProvider (line 16):

  view:
    label: View Commit
    class: info.magnolia.ui.contentapp.detail.DetailDescriptor
    datasource:
      $type: jsonDatasource
      restClient: bitbucket
      restCall: commit
      jsonPathExpressions:
        properties:
          author: '$.author.raw'
    actions:
      cancel:
        label: Cancel
        $type: closeAction
    itemProvider:
      $type: jsonProvider

(A snippet of an existing full definition, see https://git.magnolia-cms.com/projects/MODULES/repos/rest-client/browse/declarative-rest-demo/apps/commits.yaml#50-65.)

...

In a form definition

A provider strategy can be used applied to handle data-read operations in forms containing with complex field.  Consider For example, see the jcrChildNodeProvider in the following definition of a complex field called address , composed of two simple fields, city and country .

...