struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: [action2] Proposal: Remove explicit support for action!method syntax
Date Mon, 12 Jun 2006 02:28:09 GMT
Sure... Building on the last example...

<action name="*!*.*" class="{1}Action" method="{2}">
  <param name="id">{3}</param>
  <result name="success">/{1}.jsp</result>

Eventually, I'd like to get to the point where we define a couple of 
generic patterns, and make xwork.xml optional.  Then, you could add 
special case results and interceptor stack customizations through 
annotations, or an axillary xwork.xml for Java 1.4 users.

The one limitation Action 2 has is how the default ActionMapper 
determines a namespace.  It assumes all directories are part of a 
namespace, leaving the last path element for the Action name.  In 
Struts, the namespacing is handled differently, allowing you to use 
multiple path elements in your action name.  For example, the above 
would turn into "*/*/*", which looks more natural.  Combined with prefix 
mapping instead of extension mapping, you can have a more ReST-ful 


Bob Lee wrote:
> I finally understand wildcards! Can you give an example of using more
> than one wildcard in an action name?
> Bob
> On 6/11/06, Don Brown <> wrote:
>> With XWork now supporting wildcards in xwork.xml, I think it is time to
>> remove the explicit support for the fooAction!barMethod.action syntax.
>>  From a reading of our tickets, the legacy support for that syntax is
>> affecting the framework in strange ways, and now that we have wildcards,
>> they can be completely simulated.
>> In this case, the syntax can preserved with wildcards.  For example:
>> <action name="foo!*" method="{1}">
>> ...
>> </action>
>> A few reasons to do this:
>>  - Support was source of bugs
>>  - Possible security hole
>>  - The old argument that the number of action mapping would explode can
>> be mitigated with wildcards
>>  - Wildcards are much more flexible, and make automatic choosing of
>> methods an explicit decision on the part of the user
>> Thoughts?
>> Don
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message