[OS-webwork] Action configuration XML

[Rickard Öberg]

I'm fiddling with the action configuration XML, and here's what I have currently.

<xwork>
<package name="standard" prefixes="com.opensymphony.xwork">
<interceptor name="parameter" class="action.interceptor.ParameterInterceptor"/>

<interceptors name="default">
<interceptor-ref name="parameter"/>
</interceptors>

<result name="error" view="error.jsp"/>
</package>

<package name="examples" depends="standard" prefixes="com.opensymphony.xwork.action">

<result name="error" view="exampleerror.jsp"/>

<action name="foo" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
</action>

<action name="Bar" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="success.jsp"/>
</action>
</package>

<package name="examples2" depends="standard" prefixes="com.opensymphony.xwork.action">

<action name="foo" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
</action>

<action name="Bar" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="success.jsp"/>
</action>
</package>
</xwork>
--

There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this:
<xwork>
&standard;
&examples;
&examples2;
</xwork>
where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities:
<xwork>
&standard.xml;
&examples.xml;
&examples2.xml;
</xwork>
and here it would also be possible to add a standard entity resolver that understands properties files:
<xwork>
&standard.xml;
&examples.xml;
&examples2.properties;
</xwork>
so that simple packages can be defined using the old format.

By using XML entities one can easily put several independent packages together into one coherent application.

The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the "depends" attribute, which is used to declare what packages it "builds on", and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way:
<package name="examples" depends="standard" prefixes="com.opensymphony.xwork.action">
<interceptor name="mystuff" class="MyInterceptor"/>

<interceptors name="default">
<interceptor-ref name="mystuff"/>
<interceptors-ref name="default"/>
</interceptors>

<action name="foo" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
</action>
</package>
---
The above would override the "default" interceptor stack from the "inherited" package.

We then come to the definition of a single action:
<action name="foo" class="SimpleAction">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
</action>
---
The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only apply to that single action. This can replace action chaining to a large extent I think.
The result declaration is fairly simple, and is just a mapping from the string to the resulting view. ".action" is used to trigger chaining, to the extent that it's still needed. Default mappings can be declared at the package level (see "error" declarations above), and also follow the package dependency in order to allow overrides.

The main idea with packages is hence to both allow for generic behaviour to be easily utilized, as well as allowing it to be overriden where necessary, while maintaining a fairly strict semantics. Or that's the idea anyway :-)

When it comes to action referencing I haven't made up my mind yet what is best, but I think it's necessary to use the package name as prefix, unless an action references another action in the same package. E.g. if the "foo" action in "examples" wants to chain to "bar" in "examples2" it would use the name "examples2.bar" instead of just "bar".

What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this:
<action name="fooDefault" class="SimpleAction.doDefault">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
</action>

i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default
the result to SUCCESS) can be invoked.

Any comments on this?

/Rickard

--
Rickard Ă–berg
[EMAIL PROTECTED]
Senselogic

Got blog? I do. http://dreambean.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork