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
