-
Type: Improvement
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 5.5
-
Component/s: Layouts & Widgets, Web Common
-
Impact type:API added
-
Upgrade notes:
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)