Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well)
> -----Original Message----- > From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 11:59 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Action configuration XML [Commands] > > > > 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 > ------------------------------------------------------- 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
