<action name="commandTest"
class="com.opensymphony.xwork.SimpleAction">
<param name="foo">123</param>
<result name="error" type="chain">
<param name="actionName">bar</param>
</result>
<interceptor-ref name="static-params"/>
<command name="myCommand" method="commandMethod">
<param name="bar">456</param>
<result name="success" type="chain">
<param name="actionName">foo</param>
</result>
<interceptor-ref name="logger"/>
</command>
</action>
Why are "params" declared explicitly? What's wrong with finding them implicitly, as is done in WebWork? Sounds like a refactoring disaster waiting to happen. Any configuration that is mostly just duplication of code is a bad idea IMHO.
Also, it is in general VITAL that we try to keep the configuration required for each action/command down to a minimum. Consider the above when you have 50-100 commands/actions. That's a lot of stuff to keep track of.
This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured.
Sounds ok.
I also refactored the names of the config classes.
Configuration -> ConfigurationProvider ConfigurationFactory -> ConfigurationProviderFactory DefaultConfiguration -> DefaultConfigurationProvider
Why not XMLConfigurationProvider? I mean, that's what it is.
SimpleConfiguration -> SimpleConfigurationProvider
Why not TestConfigurationProvider? I mean, that's what it is.
I've also created 2 new classes in the ActionConfig class hierarchy to support commands:
ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig
ActionCommand has: methodName Interceptors Parameters Results resultParameters
ActionConfig adds: Class clazz TypeConverter
HierarchicalActionConfig adds: Commands
ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side.
Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-)
See above.
I'll write another email with questions about this stuff. Oh, and I think there might be more major changes to it ;-)
/Rickard
------------------------------------------------------- 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
