LayoutService (interface)

Provides the ability to obtain the XML layout for a single domain object or for all domain objects.

API

LayoutService.java
interface LayoutService {
  String toXml(Class<?> domainClass, Style style)     (1)
  byte[] toZip(final Style style)     (2)
  String toMenuBarsXml(final MenuBarsService.Type type)     (3)
}
1 toXml(Class, Style)

Obtains the serialized XML form of the layout (grid) for the specified domain class.

2 toZip(Style)

Obtains a zip file of the serialized XML of the layouts (grids) of all domain entities and view models.

3 toMenuBarsXml(MenuBarsService.Type)

Obtains the serialized XML form of the menu bars layout ( MenuBarsService ).

Members

toXml(Class, Style)

Obtains the serialized XML form of the layout (grid) for the specified domain class.

toZip(Style)

Obtains a zip file of the serialized XML of the layouts (grids) of all domain entities and view models.

toMenuBarsXml(MenuBarsService.Type)

Obtains the serialized XML form of the menu bars layout ( MenuBarsService ).

Implementation

The framework provides a default implementation, o.a.i.core.metamodel.services.layout.LayoutServiceDefault.

The service’s functionality is exposed in the UI through a mixin (per object) and a menu action (for all objects):

  • the Object mixin provides the ability to download the XML layout for any domain object (entity or view model).

  • the LayoutServiceMenu provides the ability to download all XML layouts as a single ZIP file (in any of the three styles).

The XML can then be copied into the codebase of the application, and annotations in the domain classes removed as desired.

Styles

Each of these actions take as a parameter an instance of Style.

The CURRENT style corresponds to the layout already loaded for the domain class, typically from an already persisted layout.xml file. The other three styles allow the developer to choose how much metadata is to be specified in the XML, and how much (if any) will be obtained elsewhere, typically from annotations in the metamodel. The table below summarises the choices:

Table 1. Styles
Style @MemberOrder @ActionLayout, @PropertyLayout, @CollectionLayout

COMPLETE

serialized as XML

serialized as XML

NORMALIZED

serialized as XML

not in the XML

MINIMAL

not in the XML

not in the XML

As a developer, you therefore have a choice as to how you provide the metadata required for customised layouts:

  • if you want all layout metadata to be read from the .layout.xml file, then download the "complete" version, and copy the file alongside the domain class.

    You can then remove all @MemberOrder, @ActionLayout, @PropertyLayout and @CollectionLayout annotations from the source code of the domain class.

  • if you want to use layout XML file to describe the grid (columns, tabs etc) and specify which object members are associated with those regions of the grid, then download the "normalized" version.

    You can then remove the @MemberOrder annotations from the source code of the domain class, but retain the @ActionLayout, @PropertyLayout and @CollectionLayout annotations.

  • if you want to use layout XML file ONLY to describe the grid, then download the "minimal" version.

    The grid regions will be empty in this version, and the framework will use the @MemberOrder annotation to bind object members to those regions.

See also

The functionality of LayoutService is surfaced in the user interface through a related mixin and menu action. See also Style, which determines how much data is included in the downloaded XML.

The GridService is responsible for loading and normalizing layout XML for a domain class. It in turn uses the GridLoaderService and GridSystemService services.