[
https://jira.nuxeo.org/browse/NXP-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thierry Delprat updated NXP-4961:
---------------------------------
Status: Open (was: Triage)
> Improve the Action system
> -------------------------
>
> Key: NXP-4961
> URL: https://jira.nuxeo.org/browse/NXP-4961
> Project: Nuxeo Enterprise Platform
> Issue Type: Improvement
> Affects Versions: 5.3.1
> Reporter: Thierry Delprat
> Assignee: Thierry Delprat
> Fix For: 5.3.2
>
>
> # Why we should improve the current Action system
> The current Action system works and is used almost everywhere in the JSF
> WebApp.
> Nevertheless, I think it's time to improve it.
> There are several reasons for that.
> ## Make configuration more flexible
> Current Actions implementation let UI template choose how to diplay the
> action, not only in term of pure presentation but also in terme of type : JSF
> Post, simple GET, JS call ...
> As a consequence, each Action category is expected to contains actions that
> should all be rendered the same way.
> This worked so far, but it as begun to be a problem :
> - some links that could be action are still hard coded because of this
> - we have already begun to introduce fake categories to walk around this
> problem
> - it's hard for people customizing Nuxeo to understand these limitations
> ## Studio integration
> If we want to be able to use studio to add and configure actions.
> We will need to add more flexibility, otherwise the Studio UI will be
> cumbersome and we will have display issues.
> ## Operation integration
> We (mainly Bogdan) are currently working on a new Operations system.
> The idea is to let a Studio user define an operations chain (like update
> document + copy it somewhere + create a task ...).
> Basically, these chains will be triggered by 2 means :
> - non interactive : typically an event listener
> - interactive : a button in the UI
> In the first case, the operation chain will be conditionned by rules (using
> drools).
> For interactive triggered operations, they will need to be bound to an action
> that will be responsible for UI + guards.
> For that use case too, we need to make the Action system more flexible : we
> may want to plug an Action-Operation in a category that currently only
> supports links or JS.
> ## CMIS
> CMIS has a notion of allowable actions.
> Current implementation in nuxeo-chemistry is mainly hard coded, but in a near
> future, we may want to have someting more powerfull and leverage :
> - DM actions
> - Operations
> For this use case, we will need to change the Action definition and the guard
> definition to make this usable outside of the seam context.
> ## MSOffice integration
> We have planned to improve the integration between Nuxeo and MS Office.
> In addition of doing the "save in Nuxeo", we may want to expose more Nuxeo
> features to the MSOffice user :
> - lock-unlock a document
> - change lifecycle
> - start a WF
> - ...
> My guess is that a signgificant part of these MSO actions will be very much
> like :
> - some actions already present in DM
> - some actions we will want to expose in CMIS
> We can also expect that a SI that uses Studio to create new Action/Operation
> to apply some business processing to DM will be happy to expose this to the
> MSOffice user too.
> # What has to be improved
> ## Action types
> We should add a type attribute on the Action descriptor.
> This type attribute will be responsible for defining how the action should be
> rendered (link, button, ...) and executed (GET, JSF Post, JS ...) (may be we
> should have 2 separated attributes).
> We have to provide full backward compatibility, but since currently each
> Category is implicitly bound to a type, simply defining a default type per
> Category should be enought.
> ## JSF Rendering
> Ideally, we should provide a Tag to render an action according to it's type.
> As a first step we can simply use facelets and ui:decorate, but the target
> solution may be to have either a completly dedicated tag, or to render
> actions using layouts and widgets.
> ## Filter and Context evaluation
> The current implementation has at least 2 problems :
> - we use JEXL that is not stardard
> => we should align an a standard EL
> - Seam context integration is a hack in the deployment system
> => this is dirty and a blocking point for using actions outside of Seam
> ==> we should provide a Seam aware context from the WebActionBean and not
> have a hack in the action-core service
> ( need to change API for context definition )
> ## Integration
> We should use the action system in :
> - Nuxeo-Chemistry
> - LiveEdit API
> - (ideally) web engine links system
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.nuxeo.org/secure/Administrators.jspa
-
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
