Composite EntityViews

To understand a Composite EntityView, consider a page in the user interface (for example, the page where the business user views an order).

The Order page is further broken up into sections (details, shipments, payments, entitlements, and so on). The Composite EntityView represents how that page is organized and what actions are available so that the user interface can simply render the view to form a usable, extensible page without having any custom logic.

A Composite EntityView includes a master view and child views.

The master view represents the overall page itself. It normally does not contain properties, but could. The master view contains a list of child views that each represent a section of the user interface. It also contains a list of actions that can be executed against the entity. An example of a child view is the Details section of a page. For example, on an Order page, the child view is the section that presents the order confirmation identifier, the date, and so on.

The view represents what should be displayed in the section, so it can be extended by plugins to display additional information. Properties can vary based on some aspect of the entity, such as the type of order. It is also possible to display some properties to some users and not to others; this is a form of security trimming.

If an Order does not need to have a section, the Composite EntityView for that page does not return that section. For example, a digital product order would not have a shipments child view returned.

The view also provides an extensibility point, so you can deploy a plugin that ties into the pipelines and returns additional child views, or augments existing views with new properties.

Using the master view allows the entire web page to be returned in one call, promoting efficiency. It is also possible to call an individual child view separately. This might be required, for example, when the user wants to refresh a single section without rebuilding the entire page.