"Careful with that axe Eugene"
The only change in xwork would be in
AbstractMatcher:replaceParameters, because that method gets the params
defined in the action mapping (<param name="name">{1}</param>), and
replaces it with the value extracted from the URL. My change is to
also include additional params, so the field names don;t have to be
defined with "param". If we want to support wildcard references by
name also, it would require another change (still backward
compatible), right now only {\d} are replaced. The rest of the code
is in a custom matcher which can be used by setting
"struts.patternMatcher".
musachy
On Thu, Sep 24, 2009 at 6:05 PM, Wes Wannemacher <w...@wantii.com> wrote:
> Be careful overriding the pattern matcher. I use it in xwork to
> include files in the xml configuration provider.
>
> -W
>
>
> On 9/24/09, Musachy Barroso <musa...@gmail.com> wrote:
>> meh, this one didn't put up much of a fight :). With these set
>> ("regex" alternative implementation of patternMatcher):
>>
>> <constant name="struts.enable.SlashesInActionNames" value="true"/>
>> <constant name="struts.mapper.alwaysSelectFullNamespace" value="false"/>
>> <constant name="struts.patternMatcher" value="regex" />
>>
>> I can do this:
>>
>> <package name="regex" extends="struts-default" namespace="/">
>> <action name="/{bio:.+}/test/{name}/.*"
>> class="org.apache.struts2.showcase.UITagExample">
>> <result>/tags/ui/example.jsp</result>
>> </action>
>> </package>
>>
>> calling "/WorldDomination/test/LexLuthor" will set "bio" to
>> "WorldDomination" and "name" to "LexLuthor". The regular expressions
>> can be simple, like {name} or they can define the field name and the
>> regex like "{name:some_reg_ex_here}". The notation {X} still works, so
>> this can be done:
>>
>> <result>/tags/ui/{2}.jsp</result>
>>
>> Idea shamelessly copied from JAX-RS, I will commit it later when I
>> have more tests in place.
>>
>> musachy
>>
>> On Thu, Sep 24, 2009 at 2:19 PM, Musachy Barroso <musa...@gmail.com> wrote:
>>> I find that using parameters in urls is confusing in struts, and there
>>> are just too many (and not compatible) ways of doing it, for example,
>>> if you want to have parameters in front of the action name, like
>>>
>>> /something/param1/param2/ActionName
>>>
>>> you would have to use the "namedVariable" action mapper, but then, you
>>> cannot have parameters after the action name ("ActionName"). If you
>>> want to have parameters after the action name, then you can use
>>> wildcards, and do something like:
>>>
>>> <package name="edit" extends="struts-default" namespace="/edit">
>>> <action name="/person/*"
>>> class="org.apache.struts.webapp.example.EditAction">
>>> <param name="id">{1}</param>
>>> <result>/mainMenu.jsp</result>
>>> </action>
>>> </package>
>>>
>>> And maybe, you can mix them, but I haven't tried that. I find all this
>>> very confusing and hard to understand. I would like to do this:
>>>
>>> class MyAction {
>>> String param1, param2, param3;
>>>
>>> �...@action("/{param1}/{param2}/MyAction/{param3}")
>>> public void execute() {....}
>>> }
>>>
>>> and the framework should figure out the rest for me. I don't think
>>> this would be that hard to implement and should provide an unified way
>>> of handling these type of urls. Thoughts?
>>>
>>> musachy
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org
>>
>>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
