You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by stanlick <st...@gmail.com> on 2008/03/16 01:42:02 UTC

Wildcard mapping should not suck (but does)

I am writing what should have been the simplest three page wizard ever.  It
involves a single wildcard action mapping

<action name="wizard_*" class="acme.action.wizard.Wizard" method="{1}">
    <interceptor-ref name="starterStack">
      session
    </interceptor-ref>
    <result name="input">/pages/wizard/${currentPage}.jsp</result>
    <result>/pages/wizard/${currentPage}.jsp</result>
</action>

 and four pages 

pageOne.jsp, pageTwo.jsp, pageThree.jsp, and thanks.jsp.

Three pages need to be validated so I created 

Wizard-wizard_pageTwo-validation.xml [validate page1]
Wizard-wizard_pageThree-validation.xml [validate page2]
Wizard-wizard_pagedone-validation.xml [validates page3]

After hours of messing around with web pages coded as follows:

<html>
	<body>
	<H2>Page One</H2>
		<s:form>
			blah, blah, blah
			<s:submit method="pageTwo" key="next"/>
		</s:form>
	</body>
</html>

I discovered the method attribute of the <s:submit /> tag ignores the
validation completely!  After reading through the DefaultActionMapper source
code I discovered the METHOD_PREFIX case of the PrefixTrie logic does not
handle this case correctly so I started looking for the one-off technique. 
I modified my pages by changing the <s:submit /> tag as follows

<s:submit action="wizard_pageTwo" key="next"/>

Now the validations are being considered, however pages 2, and 3 do not
output any error messages associated with the fields failing their
validations.  The navigation to a successive page is prevented (which is
correct) but the user has no idea what is wrong!  I have looked over the
files a dozen times and cannot figure this one out.  Does anyone have any
clues?

Thanks,
Scott




-- 
View this message in context: http://www.nabble.com/Wildcard-mapping-should-not-suck-%28but-does%29-tp16074328p16074328.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts] Wildcard mapping should not suck (but does)

Posted by stanlick <st...@gmail.com>.
I had been using only the method attribute on the <s:submit/> tag until
discovering it was causing to water to run uphill when it came to the
validators.  I started experimenting and landed on moving the method
settings over to the action on the tag.  I toyed around with deferring to
the action attribute on the <s:form/> tag at one point but didn't see any
change.

So do you see any reason why my field errors are not being generated in the
HTML from the <s:textfield/> tags?

Scott



DNewfield wrote:
> 
> stanlick wrote:
>> I discovered the method attribute of the <s:submit /> tag ignores the
>> validation completely!
> 
> Not only this, but it's also a potential security hole, and might be 
> going away or being made to require more configuration in the future. 
> Why are you specifying the action in the submit tag instead of the form 
> tag?  (Even though you are using a single action definition, there 
> really are multiple actions in play here.)
> 
> -Dale
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Wildcard-mapping-should-not-suck-%28but-does%29-tp16074328p16079248.html
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [struts-dev] Alternate submit tag...

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Dale Newfield wrote:
> Jeromy Evans wrote:
>> Shouldn't validation just be fixed?
>
> What you really want to say in the s:submit tag is "run this action 
> instead"  what we're currently saying is "run this method instead". 
> Because of this, you're getting different validation than you want 
> because changing the method doesn't change the action selection.
>
> This isn't a validation problem, it's a problem in the ActionMapper.

Exactly.  It's a fundamental feature of webwork that actions and methods 
can be specified via request parameters.  That was augmented in the 
DefaultActionMapper to allow wildcards to specify the action and 
methods.  Over time various implementations have become out-of-sync, 
including XML Validation and every ajax tag.  The DefaultActionMapper 
has been crammed full of inconsistent options and somehow we all get by 
because we know what does or doesn't work.  It's alarming.

There's numerous unresolved JIRA issues relating to this.

>
>
> The current s:submit implementation is also causing difficulty in the 
> code base because it's been recognized as a possible security issue 
> when used with URL-based authorization checking, and while a solution 
> has been worked on, fully realizing it would require a change to the 
> struts.xml spec to add allowable alternate method white-lists to the 
> action mapping specification.
>

Agreed.  I think over-time the form and submit tags have become 
out-of-sync with other aspects struts 2.  My particular grievance is 
with the getMappingFromActionName(String) method that was added to the 
ActionMapper interface to support the form and submit tags.  At the time 
the tags were written it was easy to calculate the URL to an action, but 
then wildcard support was added, then portlet support was added (and 
removed to a plugin), then complex namespace support was added in 2.1 
(NamedVariablePatternMatcher) and these attributes don't always achieve 
the expected result.  Use them within the REST context and they're even 
more meaningless.  If I had my way, I'd deprecate the action and method 
attributes of these tags all-together. While there I'd split up the 
DefaultActionMapper so it doesn't try to be everything to everyone.

>
>
> It would solve your validation problem and many more simultaneously. 
> The only cost is that it makes the s:submit tag only work correctly if 
> the client has javascript enabled.
>

I agree javascript on the submit tag works-around the problem, but it's 
just a band-aid for one part of the problem.  And you're right, fixing 
XML validation is also just another greater effort band-aid.  I'm tiring 
of applying band-aids, but am also concerned that some of the problems 
are bigger than any one of us.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [struts-dev] Alternate submit tag...

Posted by Dale Newfield <Da...@Newfield.org>.
Jeromy Evans wrote:
> Shouldn't validation just be fixed?

What you really want to say in the s:submit tag is "run this action 
instead"  what we're currently saying is "run this method instead". 
Because of this, you're getting different validation than you want 
because changing the method doesn't change the action selection.

This isn't a validation problem, it's a problem in the ActionMapper.
In fact, it's part of the tag library that is implemented in the 
DefaultActionMapper code, but I believe it is moreover a result of a 
unfortunately chosen specification.

If we want the s:submit tag to work as currently specified, and 
validation to work correctly as you'd like, here's the process that must 
happen:

o Use normal mechanisms for selecting action mapping.
o Notice extra parameter, and modify that action mapping (which may or
   may not yield an action mapping that your specification considers
   legal/valid).
o Re-look up (backwards) what action mapping would have been chosen had
   the input been a value that would have resulted in this newly
   described action mapping.

More importantly than this being a difficult to describe/implement 
process even once, it is in a component of the system that is undergoing 
wonderful refinement/replacement with custom action mappers of various 
flavors (many folks have written for clients, as well as a number of 
plugins, etc.) each of which need to do this same strange dance to keep 
the current s:submit working, a complexity that we have no reason to 
want to add to developers shoulders.  (And a place where I would bet 
many ActionMappers will get it wrong.)

The current s:submit implementation is also causing difficulty in the 
code base because it's been recognized as a possible security issue when 
used with URL-based authorization checking, and while a solution has 
been worked on, fully realizing it would require a change to the 
struts.xml spec to add allowable alternate method white-lists to the 
action mapping specification.

All this can be cleaned up if we allow ActionMappers to do their jobs 
without this over-specification.  If we always named actions by the same 
name, then the right action will always be looked up and usable in it's 
full specification.  If you allow both action selection by name and then 
action modification, other things that need the correct information from 
the action specification (like the validator) are likely to get the 
wrong data.

Is it really that difficult to change your submit tag from

<s:submit method="pageTwo" key="next"/>

to

<s:submit action="wizard_pageTwo" key="next"/>
?  That's what you name the action everywhere else (in 
Wizard-wizard_pageTwo-validation.xml for example).

It would solve your validation problem and many more simultaneously. 
The only cost is that it makes the s:submit tag only work correctly if 
the client has javascript enabled.

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Alternate submit tag...

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Shouldn't validation just be fixed?

The root problem is that validation only uses the action alias and 
doesn't check if a method name is provided in a parameter.
The user of a wildcard just works-around that limitation to creating an 
alias it can match.

For historical reasons there's at least two ways to specify which action 
and method should be invoked but XML validation doesn't support both.  
Perhaps it's not possible or too slow for the validator to examine the 
ActionMapping though.

Dale Newfield wrote:
> As evidenced by the diffulties described on the user list in "Wildcard 
> mapping should not suck (but does)", I propose that instead of having a 
> method attribute on the submit tag that works w/o js in the client, but 
> requires some black magic on the server side, we add an "action" attribute 
> to the submit tag that uses js on the client to change the form target 
> before submitting.  This will enable the usage pattern that I believe 
> developers want and reduces the dispatcher complexity.
>
> Thoughts?
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [struts-dev] Alternate submit tag...

Posted by Dale Newfield <Da...@Newfield.org>.
Antonio Petrelli wrote:
> 2008/3/17, Dale Newfield <Da...@newfield.org>:
>> We can avoid the JS requirement if we make the submit button's submitted
>> value complex enough to encode the names of the namespace and
>> actionname.
> 
> The problem is that the value of the submit button is what the users sees.

The value, but not the name.

We could have <s:submit action="fred"/> result in:
<input type="submit" name="replacementAction:/namespace/fred" 
value="Make it Fred!"/>
which would result in
http://app-server/application/namespace/barney.do?replacementAction:/namespace/fred=Make+it+Fred%21
which would cause the action mapper to select the barney action, but 
then drop it on the floor and instead return the fred action.

> There is the need of a js function that modifies it before submitting.

We've got lots of struts2 tags that require javascript.  Has a chart 
ever been drawn up so that folks that need their applications to work on 
browsers either w/o javascript capabilities or w/o javascript enabled?

If the only current tags that require JS are funky ones like 
optiontransferselect, then that's a strong reason not to add the 
restriction to something as fundamental as the submit tag.  If the js 
requirements are already widespread, then that argument doesn't hold 
much water.

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [struts-dev] Alternate submit tag...

Posted by Antonio Petrelli <an...@gmail.com>.
2008/3/17, Dale Newfield <Da...@newfield.org>:
>
> We can avoid the JS requirement if we make the submit button's submitted
> value complex enough to encode the names of the namespace and
> actionname.



The problem is that the value of the submit button is what the users sees.
You don't want your user to see:
org.apache.struts2.action.MyAction.myMethod, right? :-)
There is the need of a js function that modifies it before submitting.

Antonio

Re: [struts-dev] Alternate submit tag...

Posted by Dale Newfield <Da...@Newfield.org>.
Antonio Petrelli wrote:
> Sincerely I don't like to put js where it is not necessary.

Agreed, although I'm much less worried about this today than I was 5 
years ago.

> If you don't know it, Struts 1 has "LookupDispatchAction" that makes
> a reverse-lookup in a resource bundle to retrieve the key and then
> maps it to a method. See: 
> http://struts.apache.org/1.x/apidocs/org/apache/struts/actions/LookupDispatchAction.html

I did not know--thanks for pointing it out.

If the only thing different between two concrete action definitions is 
the method, then both this mechanism and the one we're currently using 
will work.

If you have either multiple explicit action definitions, or use wildcard 
mappings, or probably other mechanisms I'm missing, this can result in a 
selected action definition that simply does not appear as a valid choice 
in your specification.  (Because instead of selecting a new one, a 
modification of the first selected one is returned.)

What I'm really arguing for is to make developers always refer to 
actions by namepace&name, so that we can always select the correct valid 
action specification.

We can avoid the JS requirement if we make the submit button's submitted 
value complex enough to encode the names of the namespace and 
actionname.  Instead of returning a modification of an action mapping, 
the action mapper then could completely ignore the action mapping it 
would normally select and select a different one based on these two 
strings.  This wouldn't help with WW-2316/WW-2363/XW-595/XW-594, but it 
would fix this validation problem...

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Alternate submit tag...

Posted by Antonio Petrelli <an...@gmail.com>.
2008/3/16, Dale Newfield <Da...@newfield.org>:
>
> I propose that instead of having a
> method attribute on the submit tag that works w/o js in the client, but
> requires some black magic on the server side, we add an "action" attribute
> to the submit tag that uses js on the client to change the form target
> before submitting.



Sincerely I don't like to put js where it is not necessary. If you don't
know it, Struts 1 has "LookupDispatchAction" that makes a reverse-lookup in
a resource bundle to retrieve the key and then maps it to a method. See:
http://struts.apache.org/1.x/apidocs/org/apache/struts/actions/LookupDispatchAction.html

Ciao
Antonio

Alternate submit tag...

Posted by Dale Newfield <Da...@Newfield.org>.
As evidenced by the diffulties described on the user list in "Wildcard 
mapping should not suck (but does)", I propose that instead of having a 
method attribute on the submit tag that works w/o js in the client, but 
requires some black magic on the server side, we add an "action" attribute 
to the submit tag that uses js on the client to change the form target 
before submitting.  This will enable the usage pattern that I believe 
developers want and reduces the dispatcher complexity.

Thoughts?

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [struts] Wildcard mapping should not suck (but does)

Posted by Dale Newfield <Da...@Newfield.org>.
stanlick wrote:
> I discovered the method attribute of the <s:submit /> tag ignores the
> validation completely!

Not only this, but it's also a potential security hole, and might be 
going away or being made to require more configuration in the future. 
Why are you specifying the action in the submit tag instead of the form 
tag?  (Even though you are using a single action definition, there 
really are multiple actions in play here.)

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org