Potential Wildcard mapping bug? (Re: Change dinamycly the input parameter of an action)

[Joe Germuska <Jo...@Germuska.com>]

Before you file ea bug, please do as much as you 
can to be sure there's a real bug, and if 
possible, provide a test case.  (in theory, this 
is something which should be verifiable with a 
JUnit test, although some parts of Struts are 
still a bit complicated to "mock".  I haven't 
looked in this specific case.)

The only reason I add these cautions are that I 
have been using wildcard mapping successfully 
without any unpredicted behavior.  I wouldn't say 
I use it extensively, but it has seemed reliable 
for my needs.  Is there any chance that you have 
two wildcard mapped actions, and one is being 
matched instead of the other?

From your example, I wonder why "filtro" and 
"pag" aren't part of the part which is matched 
and then applied with a pattern.

Were you already using wildcard patterns before 
this came up?  Or is this the first time you're 
implementing them?

I certainly am not claiming that it couldn't be a 
Struts bug, but it helps if people only file bug 
tickets after a decent amount of verification.

Once you've done that verification, go here:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Struts

and provide as much info as you can, again, 
preferably including some kind of test case.

Thanks
	Joe


At 2:36 PM +0200 4/28/05, Rodolfo García Esteban/CYII wrote:
>Hi Joe,
>
>Well I have followed your advise, I create other action mapping to the
>same path. I used matches before, and I find and error in Struts.
>
>My original action is
>
>         <action
>             path="/*Action"
>             type="es.cyii.cpd.action.{1}Action"
>             ...
>             input="pag{1}Page"
>             validate="true"
>             name="{1}Form">
>                 ...
>         </action>
>
>The new action would be (doesn't work)
>         <action
>             path="/Consulta*Action"
>             type="es.cyii.cpd.action.{1}Action"
>                 ...
>             input="filtro{1}Page"
>             validate="true"
>             name="{1}Form">
>                 ...
>         </action>
>
>Well with this new action if the call is "/ConsultaAccessAction" the form
>to look for would be AccessForm, but
>struts 1.2.4 looks for ConsultaAccessForm. Doesn't work very well the
>matches.
>
>The new action is
>         <action
>             path="/ConsultaAccessAction"
>             type="es.cyii.cpd.action.AccessAction"
>                 ...
>             input="filtroAccessPage"
>             validate="true"
>             name="AccessForm">
>                         ...
>         </action>
>
>In the case of the first <action  path=*Action>, when there is an error it
>returns to the input page and show the inputs fills with data, but in the
>second case <action path="/ConsultaAccessAction"> when there is an error.
>The form is reseted. Do you know why? I think is other bug.
>
>Are you a committer? With this message the bugs are reported or I should
>report them in other way?
>
>Thank you Joe
>
>________________________
>Rodolfo
>_______________________
>
>
>
>
>Joe Germuska <Jo...@Germuska.com>
>27/04/2005 16:07
>Por favor, responda a "Struts Users Mailing List"
>
>
>         Para:   "Rodolfo García Esteban/CYII" <rg...@cyii.es>,
>user@struts.apache.org
>         cc:
>         Asunto: Re: Change dinamycly the input parameter of an action
>
>
>At 3:38 PM +0200 4/27/05, Rodolfo García Esteban/CYII wrote:
>>Hi
>>
>>I'm using struts 1.2.4. I have an action which can be called from two
>>pages, and I need to change the input parameter in order to return and
>>show the errors in the previous page, by this cause I can't specify the
>>input parameter in struts-config.xml, I need to do something in my
>>application dinamycly.
>
>There are two direct work-arounds, although neither may totally satisfy
>you:
>
>a) use more than one action mapping, so that each
>of two paths can have independent values for
>"input" while sharing most of the rest of the
>config, as well as sharing the processing logic.
>This may be easier using wildcard path
>mapping[1], which allows you to populate values
>of the ActionMapping based on matches, so you
>could have:
>
><action path="/usecase/SubmitFrom*" input="{1}" ...>
>
>This might work better with the ability to
>specify that values for "input" are forward names
>rather than application paths.[2]  Of course, you
>don't have to use wildcards.
>
>We've recently also added support for "extending"
>config elements, although I believe this is only
>in the Struts 1.3 dev branch (did it get added to
>1.2.x?)  That would provide an alternative
>approach.
>
>b) perform the validation inside your action and
>manually return the correct forward config object
>based on the context.  This is really not that
>hard.  Here's how you'd do in an action what
>Struts does for you if "validate" is set to
>"true"; from here, you should be able to adapt to
>return a different forward.:
>
>public ActionForward execute(m,f,req,res)  throws Exception{
>    // replicate Struts validation
>    ActionErrors errors = f.validate(m,req);
>    if (errors.size != 0) {
>      saveErrors(req,errors);
>      return m.getInputForward();
>    }
>    // carry on with valid-state controller logic
>}
>
>A lot of Struts users have valid reasons to do
>the validation inside the action instead of
>leaving it up to Struts -- maybe you are one of
>them.  To be honest, though, I think the first
>solution is a better one, whether or not you use
>wildcards.
>
>Joe
>
>References:
>[1]
>http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards
>[2] http://struts.apache.org/userGuide/configuration.html#controller_config
>--
>Joe Germuska
>Joe@Germuska.com
>http://blog.germuska.com
>"Narrow minds are weapons made for mass destruction"  -The Ex


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex