Improve the Action system

1. 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.

1. 1. 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

1. 1. 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.

1. 1. 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.

1. 1. 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.

1. 1. 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.

1. What has to be improved

1. 1. 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.

1. 1. 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.

1. 1. 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 )

1. 1. Integration

We should use the action system in :

• Nuxeo-Chemistry

• LiveEdit API

• (ideally) web engine links system