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

Reply via email to