Since the commit for this feature involved a rather large XWork change
(properly immutable configuration objects [1]), I decided to commit
what I have and discuss the next steps.

First, due the aforementioned fix [1], Brian, your SmartURL's
migration work will probably be most affected.  I changed the
configuration objects to be immutable using a static inner builder
class pattern.  This makes construction a bit tricker, so pay
attention to the changes in the code and tests for the codebehind
plugin.  The bright side is the construction code is much more
readable and nasty state bugs should be gone.  You can do nifty things
like this:

ActionConfig config = new ActionConfig.Builder("mypackage", "foo/*/*",
"foo.BarAction")
                .methodName("execute")
                .addParam("someparam", "someval")
                .addResultConfig(new
ResultConfig.Builder("success{1}", "foo.MyResult")
                    .addParams("location", "/foo.jsp")
                    .build())
                .build();

As for the allowed methods, I originally suggested three options:

1. A new property/constant titled 'struts.restrictToDeclaredMethod'
that will instruct the ActionConfig (where the allowedMethods property
lives) to only allow the method that is explicitly defined (defaults
to 'execute').  If false, all methods will be allowed.

2. A new attribute on the <action> element called 'allowedMethods',
which takes a comma-separated list of method names to allow

3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable

And after the comments, I see #2 is important and #3 I'll skip, since
Brian will be rewriting that stuff anyways.

To answer Matt's concern, yes, the default will be all public, no-arg
methods can be called, but what this will allow folks to do is limit
the methods that can be called, if they so choose.  It also makes it
clearer to the developer what methods are being exposed through tools
like the config browser plugin.  I'm also thinking it will be helpful
down the road when a plugin wants to move behind no-arg methods (I've
tried it, it can be pretty powerful).

See https://issues.apache.org/struts/browse/WW-2363

Any more thoughts?

Don

[1] http://jira.opensymphony.com/browse/XW-594

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to