[OS-webwork] XWork: core concepts

[Rickard Öberg]

All,

Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are.

The core concepts that I think must be included are the following:
* Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here.

* Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action.

* Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering.

* Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a "default" Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics.

These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies:
* Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more "portlets", it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the ".action" extension though.

* For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a "component" that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an "add-on" like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action. This also gives some extra security.

* The execution of a Component (and maybe Action's too) needs to be split into two phases. The actual execution of an action is done at the *beginning* of a page render, and the rendering is done at the time of the include. Why? Because the action may influence what is shown on the page, and may also result in a redirect to another page. If the action execution is done at the point of the include it's too late to do a redirect, and other portlets may have rendered state that is then changed by the action execution. (This thinking, by coincidence, mirrors well how the portlet API will work)

* When rendering URL's, the parameters need to be namespace'd in order to allow several portlets to happily live together on a page. I.e. instead of having ?foo=bar one could have ?1.foo=bar&2.foo=bar. The XWork servlet dispatcher would then at execution filter out those parameters which does not apply to the action/component/portlet being executed, and only the remaining parameters are applied using the setX() initialization code. This requires the rendering code to use either a taglib (in JSP) or some JavaBean (in Velocity) which can do this encoding. I know that for *some* applications this will be overkill, but for those of use who are going beyond very simple web apps it is a definitive must.

Off the top of my head, those are the concepts and requirements I have in order to be able to use XWork in our portal/CMS application. So, what do you think?

/Rickard



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork