M
Jason Carreira wrote:
If you set up your interceptors to have the StaticParameterInterceptor
AFTER the ParameterInterceptor (which I would suggest is a good
practice) then static configuration will override runtime parameters.
I'm really talking about when you don't pass a method param (which, with
CommandDriven and the "command" param in WW1.x would cause doDefault()
to be called) or when you're trying to set it at runtime with a method
param, either of which allows the user to change the URL to change
behavior.
-----Original Message-----
From: Anthony Eden [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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.execute() to
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
set <paramcall 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
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_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
