Just my $0.02. However, it seems to me that having the action interface is a good thing. That you should use an if-else (if there is not a commandMethod parameter you cast to Action and call execute, otherwise invoke the method reflectively). While, we are talking microseconds in terms of performance, it is faster in cases where a method is not spec-ed and that will add up over time. Also, for a newbie, it doesn't seem like PFM. Given that, and there is no compelling reason to remove it( in other words it is not hurting anything ), then why put the cycles into taking it out?
LES -----Original Message----- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! IMHO this is just over complicating things. Regardless of the _removal_ of Action, I'm for removing the execute() method and just making it default. Alias = action class + method name (default to execute()) Could it get simpler? Why pass URL parameters and all this crazy complicated stuff? M On 3/7/03 6:56 AM, "Matt Ho" ([EMAIL PROTECTED]) penned the words: > I agree with you on this. A good solution to this would be to allow > Actions to implement Parameterizable. Actions marked as parameterizable > would have the static params set via the this interface as well as > through mechanism. You'd know that any params that were set via the > Parameterizable interface had come through the container and not from > the user. > > M > > Anthony Eden wrote: >> So you're saying that setting a parameter via the URL and setting a >> parameter via the xwork configuration file call the same methods. This >> sounds like a potential security hole for unsuspecting developers. >> >> FWIW, JPublish allows you to pass configuration data to actions in the >> same way that you can with xwork.xml params, but this is a different >> mechanism than using HTTP parameters. It doesn't call get and set >> methods on the action rather there is a predefined method >> loadConfiguration(). Not sure whether its better or worse, just giving >> an alternative solution to a similar problem. >> >> Sincerely, >> Anthony Eden >> >> Jason Carreira wrote: >> >>> This is how WW1.x command driven actions are implemented. What I don't >>> like about this implementation is that anyone who know a little bit >>> about how WW works can twiddle with URLs to call other methods. Maybe >>> not a huge risk, but just ugly. >>> People can choose not to use different methods on their actions, but I >>> want the ability to use it to keep from having a proliferation of Action >>> classes. >>> Jason >>> >>> >>>> -----Original Message----- >>>> From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: >>>> Wednesday, July 02, 2003 4:17 PM >>>> To: [EMAIL PROTECTED] >>>> Subject: Re: [OS-webwork] WebWork2, here I come! >>>> >>>> >>>> On Wednesday, July 2, 2003, at 03:35 PM, Jason Carreira wrote: >>>> >>>>> I find it very useful to have multiple entry points to one >>>> >>>> >>>> Action, so >>>> >>>>> you don't have to have a proliferation of Action classes >>>> >>>> >>>> and they can >>>> >>>>> share common properties and validations... If you don't >>>> >>>> >>>> have this, you >>>> >>>>> end up with people either creating class hierarchies to share this >>>>> state or passing special parameters to allow a larger >>>> >>>> >>>> grained action >>>> >>>>> to dispatch within itself, like the way ActionSupport did >>>> >>>> >>>> in WW1.x, or >>>> >>>>> they do BOTH. The ability to map aliases to entry point methods is >>>>> VERY useful for some people, myself included. >>>> >>>> >>>> You extend from ActionSupport generally? Or Action? >>>> >>>> Just for fun I coded this up: >>>> >>>> public class DispatchAction implements Action { >>>> private String method; >>>> >>>> final public void setMethod(String method) { >>>> this.method = method; >>>> } >>>> >>>> final public String execute() throws Exception { >>>> System.out.println("invoke: " + method); >>>> >>>> return SUCCESS; >>>> } >>>> } >>>> >>>> Of course just substitute the right reflection voodoo in execute() to >>>> call whatever method you want. I'd make this abstract, of course, >>>> and that is why I made the two methods final. In xwork.xml I set >>>> <param name="method">someMethod</param> and have the static >>>> interceptor configured. With the dynamic param interceptor also in >>>> the stack I was able to switch the method from ?method=blah too. >>>> >>>> What is wrong with that approach with how you want things to work? >>>> Just because of subclassing? >>>> >>>> Erik "still +1 on Action, with no other entry points" :) >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites >>>> including Data Reports, E-commerce, Portals, and Forums are available >>>> now. Download today and enter to win an XBOX or Visual Studio .NET. >>>> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06 >>> >>> >>> 1203_01/01 >>> _______________________________________________ >>> Opensymphony-webwork mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >>> Data Reports, E-commerce, Portals, and Forums are available now. >>> Download today and enter to win an XBOX or Visual Studio .NET. >>> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >>> _______________________________________________ >>> Opensymphony-webwork mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >> Data Reports, E-commerce, Portals, and Forums are available now. >> Download today and enter to win an XBOX or Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >> _______________________________________________ >> Opensymphony-webwork mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
