LayoutService
Provides the ability to obtain the XML layout for a single domain object or for all domain objects.
API
interface LayoutService {
String toXml(Class<?> domainClass, LayoutExportStyle style) (1)
byte[] toZip(LayoutExportStyle style) (2)
String toMenuBarsXml(MenuBarsService.Type type) (3)
}
1 | toXml(Class, LayoutExportStyle)
Obtains the serialized XML form of the layout (grid) for the specified domain class. |
2 | toZip(LayoutExportStyle)
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, LayoutExportStyle)
Obtains the serialized XML form of the layout (grid) for the specified domain class.
toZip(LayoutExportStyle)
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
.
Related Mixins and Menus
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:
Style | @ActionLayout#sequence, @PropertyLayout#sequence, @CollectionLayout#sequence | @ActionLayout#fieldSetId, @PropertyLayout#fieldSetId |
---|---|---|
|
serialized as XML |
serialized as XML |
|
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
@ActionLayout
,@PropertyLayout
and@CollectionLayout
annotations from the source code of the domain class.
-
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
@ActionLayout
,@PropertyLayout
and@CollectionLayout
annotations to bind object members to those regions, and to specify their order within 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.