See, I just think it's invaluable for action re-use to be able to lock down certain parameters for various aliases, even if the action classs is the same. For example:
In my document/workflow management system, we have various businessgroups that can create documents. Ideally, there could be a FooCreateDocument and BarCreateDocument action aliasing, both maping to com.cisco.CreateDocument. The only different would be that each alias would have a different value for the "businessGroup" parameter (one has Foo, one has Bar). Yes, this could be done with CreateDocument.action?businessGroup=Foo, but then the burdon is on the HTML/JSP writers and not the application designer. -Pat ----- Original Message ----- From: "Rickard Öberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 02, 2003 9:41 AM Subject: Re: [OS-webwork] Action configuration XML [Commands] > Patrick Lightbody wrote: > > 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. > > But it's a dangerous option, since it may not be apparent that this > slowdown will occur. If possible, configuration of actions should not > occur this way. > > > 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. > > Well, I wanted to see if commands maybe could be put in as a core concept. > > > 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). > > No, you now have two reflective calls: the parameter and the execution. > If this is the only reason to use parameters, the case is a bit weak. > > > 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). > > I think having an option which will lead to foot-shooting is a bad idea. > And I don't think documentation is a solution for that either. > > /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 ------------------------------------------------------- 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
