[
https://jira.nuxeo.com/browse/NXP-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian updated NXP-7614:
-------------------------------------
Description:
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)
was:
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.
Summary: Extract LayoutManager service independent from the JSF layer
(was: Extract LayoutManager service (subset of WebLayoutManager) that does not
depend on JSF layer)
> Extract LayoutManager service independent from the JSF layer
> ------------------------------------------------------------
>
> Key: NXP-7614
> URL: https://jira.nuxeo.com/browse/NXP-7614
> Project: Nuxeo Enterprise Platform
> Issue Type: Improvement
> Components: Web Foundations
> Reporter: Thierry Delprat
> Assignee: Anahide Tchertchian
> Fix For: 5.5
>
>
> 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)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
