> 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?
I think that the ability to have parameters applied before the action is
initialized is a feature needed, even if it could be slow. For the most part
there will be zero params, so the slowdown isn't an issue. Commands, in my
opinion, should not be part of the configuration if they aren't part of the
core framework -- meaning that since ActionSupport deals with commands but
Action is the only core part of the framework, commands don't deserve
special treament.
That was where I got the idea for having parameters that would be applied
before the Action is executed. So with that said, I think commands should be
configured like so:
<action name="fooDefault" class="SimpleActiont">
<interceptors-ref name="default"/>
<result name="success" view="bar.action"/>
<params>
<param name="command">default</param>
</params>
</action>
The end result is the same (since commands needed reflection anyway). The
only difference is that there is an option for even more flexability, but no
one has to use it if they are worried about reflection (though since every
single HTTP request parameter is also reflected, I see no big problem by
adding this as well).
-Pat
-------------------------------------------------------
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
