The <s:submit method="" /> approach definitely works for specifying
specific methods on the action, and actually works via the
org.apache.struts2.dispatcher.mapper.DefaultActionMapper class (the same
class that makes the <s:submit action="" /> work).
Anyway, you are right about the different approaches creating different
aliases... I changed my configuration to use the wildcard approach and
that DID work.
I *think* that the reason the <s:form action="crud"><s:submit
method="save" /></s:form> approach does not produce the desired
"MyAction-crudsave-validation.xml" match is that this approach does not
modify the actual action name and therefore only matches on
"MyAction-crud-validation.xml".
For reference, here is my revised (working) configuration:
struts.xml:
-----------
<package name="myPackage" namespace="/myNamespace"
extends="struts-default">
<action name="index" class="mySpringAction" method="browse">
<result name="browse">/WEB-INF/jsp/browse.jsp</result>
<interceptor-ref name="defaultStack" />
<interceptor-ref name="store">
<param name="operationMode">RETRIEVE</param>
</interceptor-ref>
</action>
<action name="crud_*" class="mySpringAction" method="{1}">
<result name="input">/WEB-INF/jsp/form.jsp</result>
<result name="success" type="redirect-action">index</result>
<result name="browse" type="redirect-action">index</result>
<result name="cancel" type="redirect-action">index</result>
<interceptor-ref name="defaultStack" />
<interceptor-ref name="store">
<param name="operationMode">STORE</param>
</interceptor-ref>
</action>
</package>
MySpringAction.java:
--------------------
public class MySpringAction extends ActionSupport {
public String browse() throws Exception {
// do some stuff
return BROWSE;
}
public String input() throws Exception {
// do some stuff
return INPUT;
}
public String save() throws Exception {
// do some stuff
return SUCCESS;
}
public String delete() throws Exception {
// do some stuff
return SUCCESS;
}
public String cancel() throws Exception {
// do some stuff
return CANCEL;
}
}
form.jsp:
---------
<s:form action="crud">
<!-- form stuff in here -->
<s:submit action="crud_save" />
<s:submit action="crud_delete" />
<s:submit action="crud_cancel" />
</s:form>
validation file(s):
-------------------
MySpringAction-crud_save-validation.xml
So, what was the goal of all this?
----------------------------------
When the "Save" button is pressed, the form is validated using
"MySpringAction-crud_save-validation.xml". When the "Delete" or
"Cancel" buttons are pressed, no validation is performed. however, if
validation was needed for these, validation files could be created for
them: "MySpringAction-crud_delete-validation.xml" and
"MySpringAction-crud_cancel-validation.xml", respectively.
Thanks for your help Jeromy!
- Patrick Crocker.
-----Original Message-----
From: Jeromy Evans [mailto:[EMAIL PROTECTED]
Sent: Monday, July 02, 2007 6:04 PM
To: Struts Users Mailing List
Subject: Re: [S2] Validation alias
Crocker, Patrick wrote:
> Unfortunately, I can't get that
> (MySpringAction-crudsave-validation.xml)
> to work. The validation never fires. Am I missing something, or just
> barking up the wrong tree all-together?
>
>
The last time I checked you had to use the wildcard approach to call
methods in your action rather than via the method="" attribute in the
form. At the very least, the two different methods create different
aliases that the validation interceptor searches for and the
documentation describes the former approach.
ie. This will find MySpringAction-crudsave-validation.xml
<action name="crud*" class="mySpringAction" method="{1}">
...
<s:form action="crud">
<!-- form stuff in here... -->
<s:submit action="crudsave" />
</s:form>
I never investigated what the validation filename should be for the
method="" approach, sorry, but this will get you closer.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
