Show last authors
1 {{include document="XWiki.DesignClassSheet"/}}
3 {{warning}}
4 First version implemented and documented as the [[Action API Module>>extensions:Extension.Action API]].
5 {{/warning}}
7 The need is to develop the Action module of the XWiki platform, i.e. the module that is the entry point for all UIs and in charge of calling the correct backend code to display what the user has asked for (it's the Controller in MVC terminology).
9 = Requirements & Use cases =
11 * UC1: Actions should be able to be added without touching at the existing platform code (i.e. someone could write a new action in java and plug it in)
12 * UC2: It should be possible to execute something before or after an Action's execution.
13 * UC3: It should be possible to completely replace an Action with another implementation.
14 * UC4: It should be possible to add Actions without stopping the running XWiki instance
15 * UC5: Actions should not know about each other
16 * UC6: Actions should be independent of the URL formats used
17 * UC7: Actions should work for both Entity Resources and other Resources (such as static resources, skin resources, etc)
18 * UC8: It should be possible for an Action to be registered for one action, a list of actions or all actions
20 Some examples matching those use cases:
22 * When a browser supports gzip compression, the response should be passed through a discrete gzip Action component. However if the requested material is already compressed (images), it should not be gzip'd.
23 * If the user is not logged in and the action they are requesting does not alter the database (Registration) the request should be passed to a cache Action. If the cache contains the desired page then it is returned, otherwise it is passed on to the requested action and when returned it is added to the cache.
24 ** Vincent: This should be done by caching the XDOM using the cache macro
25 * If desired, a filter Action may catch requests depending on user agent, ip address etc. And reroute the request. Banned!
27 = History =
29 * Vincent wrote a first version located in xwiki-platform-action a long time ago. This version has been idle for a long time and in July 2012 it was decided to remove it since it wasn't used (See
30 * Before it was removed Caleb wanted to reuse it when he started working on the Captcha integration (See In the end the Captcha module was committed without making use of that action module.
32 = Latest Proposal =
34 * An ##Action## interface:(((
35 {{code language="java"}}
36 /**
37 * Executes a given {@link org.xwiki.resource.Resource}.
38 *
39 * @version $Id$
40 * @since 6.0M1
41 */
42 @Unstable
43 public interface Action
44 {
45 int getPriority();
46 List<String> getSupportedActionIds();
47 void execute(Resource resource, ActionChain chain) throws ActionException;
48 }
49 {{/code}}
50 )))
51 * An ##ActionManager## interface:(((
52 {{code language="java"}}
53 /**
54 * The Action Manager's goal is to locate the right {@link Action} implementations to call in the right order.
55 *
56 * @version $Id$
57 * @since 6.0M1
58 */
59 @Unstable
60 public interface ActionManager
61 {
62 void execute(Resource resource) throws ActionException;
63 }
64 {{/code}}
65 )))
66 * An ##ActionChain## interface:(((
67 {{code language="java"}}
68 /**
69 * Allows calling the next {@link org.xwiki.action.Action} in the chain. An instance of this class is passed to
70 * {@link Action#execute(org.xwiki.resource.Resource, ActionChain)} and it's up to the Action implementation to
71 * decide if it wants to stop the execution chain or not.
72 *
73 * @version $Id$
74 * @since 6.0M1
75 */
76 @Unstable
77 public interface ActionChain
78 {
79 void executeNext(Resource resource) throws ActionException;
80 }
81 {{/code}}
82 )))
84 These 3 interfaces support the defined use cases:
85 * UC1: ok since Actions are added as components
86 * UC2: ok by using the ##getPriority()## to order Actions
87 * UC3: ok by using component priority to replace a component impl with another one
88 * UC4: ok since our component manager supports adding/removing components at runtime
89 * UC5: this is the case with this proposal
90 * UC6: proposal is reusing the ##Resource## (from the xwiki-platform-resource module) and is thus independent of the URL format
91 * UC7: ok but the Resource module needs some minor changes. IMO we need to add a ##getAction()## API to the ##Resource## interface and not only in ##EntityResource## in order to support actions for all types of Resources.
92 * UC8: one action and a list of actions are supported. All actions can also be supported if for example we consider that if ##getSupportedActionIds()## returns an empty list it means it's registered for all actions.
94 Note that if required, Actions can get injected the ##Container## and thus get access to the current Request/Response. Same for the Execution Context.
96 == Migration ==
98 In order not to break existing oldcore ##XWikiAction## the idea would be to not introduce a new Servlet ATM and instead inside ##XWikiAction## to call the new ##ActionManager## after all component/execution context have been initialized and then to call as now the various Struts actions.
100 Then the idea would be to migrate one by one the struts Actions to the new API. Once no more action remain, we would move the struts code into a legacy module as much as possible (which BTW would be easier if we move to Servlet 3.0 since the servlet could be moved there and still work without a mapping in web.xml).

Get Connected