Affects Version/s: None
Fix Version/s: 5.5
Impact type:API added
removed interfaces LayoutManagerLocal and LayoutManagerRemote: LayoutManager is enough added method LayoutManager#getDefaultStoreCategory added new service LayoutStore handle storage and retrieval of layout items, independant from JSF layout runtime descriptors do not follow corresponding layout interfaces anymore See the issue comments for details.
- removed interfaces LayoutManagerLocal and LayoutManagerRemote: LayoutManager is enough
- added method LayoutManager#getDefaultStoreCategory
- added new service LayoutStore handle storage and retrieval of layout items, independant from JSF
- layout runtime descriptors do not follow corresponding layout interfaces anymore
See the issue comments for details.
For now the WebLayoutManager service depends on JSF layer because of EL resolution requirements.
In some cases it would be useful to have a non-JSF LayoutManager that contains only the logic used for managing the LayouDefinition, WidgetDefinitions.
For exemple, in order to be able to have full JSON export of a Layout including non-local widgets, we need to access the WebLayoutManager, but it creates a dependency issue that prohibit to use the bundle in a non-JSF environement.
=> split interfaces (currently LayoutManager interface already holds WebLayoutManager interface methods that do not depend on JSF classes) so that the low-level layout service handles:
- widget types, widgets and layouts registries for a given category. This will make it possible to define widget instances in specific categories (for instance to declare global widget instances only used in widgets types configuration doc). And this will prepare work for a layout service managing widget types for freemarker/gwt layout system for instance.
- layout/widget definition conversion: the forms-layout-io plugin currently depends on core-api and directory-api to perform conversions of definitions to be rendered on a mobile (android plugin need) and this could be interesting for other features (for instance gadgets, in case freemarker can render a layout someday) as well as layout preview (as some configuration would need to be filtered otherwise preview would fail)