Don Brown wrote:
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();
At first I thought this might be a problem because SmartURLs was
sub-classing the ActionConfig object in order to add some additional
information for performance reasons. However, I have a feeling that I
can remove the sub-class. All the same, I think your change still allows
sub-classing. Now I just need to figure out if I want to remove my
sub-class or not :)
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.
I've got some work done on the new convention plugin and put together a
short design doc for it because I kept getting lost in the soup of
conventions and configuration overrides. Here's the URL for the design doc:
http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-convention-plugin/design.txt?view=markup
With respect to allowed methods, the new plugin only generates
configuration for the execute method and any other method that is
annotated. So, with the new allowedMethods property inside the
ActionConfig, it should be a snap to just ensure that when the plugin is
constructing the ActionConfig instances it locks down the Action
accordingly.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
