Help me better understand Struts2, validation, and stateful actions - validation

Question

As I understand it, Struts2 action class instances can (unlike Struts1) be stateful, because each GET or POST to an action creates a new instance of the backing action class.
I also see that there's a standard(?) idiom (Pattern?) to provide input forms: the same .jsp is used as the View component of two different actions, like this:
<action name="showForm" class="defaultActionThatDoesNothingExceptReturnSuccess">
<result name="success">inputForm.jsp</result>
</action>
<action name="validateAndProcessForm" class="realAction">
<result name="input">inputForm.jsp</result>
<result name="success">formProcessed.jsp</result>
</action>
The first action just displays the form, without validating the input or processing it. The form in the .jsp posts to the second action:
<s:form action="validateAndProcessForm" method="post">
and that second action validates the posted fields/parameters, returning "input" if the form's inputs are incomplete or invalid, or actually calling the action class's execute if the inputs are complete and valid, thus processing the form and returning the (e.g.) formProcessed.jsp that displays something like "thanks for your input!".
So we have this sort of "picket fence" idiom:
defaultAction- -> realAction-
| | | |
-> input.jsp- <--- -> success.jsp
This is done so that the first time input.jsp is displayed, validations aren't called (and so validation errors are not shown), but that after the submit button on that jsp is clicked, the "real" action will validate the input, possibly passing back errors calling out invalid input which the input.jsp will display.
Which brings us back to stateful, non-singleton actions; because the action is stateful and thus not shared across GETs or POSTs, and each instance is instantiated just for that GET or POST, the action has no way to know if a particular session has "GETted" the same page multiple times. So GETting showForm.action will never validate, and GETing validateAndProcessForm will always validate (and show errors if the parameters are invalid), even if that GET is the first time a particular session has "GETted" that URL.
Which is why we need the "fence post": the first action just to display the form, the second to capture the input.
Is my understanding correct? Is there a less verbose way to do this, to not validate input on the initial GET, but to validate on the POST, without having to have two actions for every form?

Answer 1

There is another way to perform what you want without the picket fence. The validation interceptor, by default, does not fire for the input method. You can therefore update your struts.xml to the following:
<action name="*MyForm" method="{1}" class="realAction">
<result name="input">inputForm.jsp</result>
<result name="success">formProcessed.jsp</result>
</action>
With this setup, you do not need the empty action at all. When you first go to the form, you would go to the url "inputMyForm", and have your form action just point to "MyForm". The {1} in the method block just means that the framework will call whatever method matches the * from the action name. If the * match is empty, it defaults to the execute method. So you get the following kinds of actions:
inputMyForm would go to the input() method of your action class
MyForm would go to the execute() method of your action class
executeMyForm would go to the execute() method of your action class
customMethodNameMyForm would go to the customMethodName() method of your action class
Since the validator interceptor excludes any actions going to the input method, you can set up whatever validation you want for this action, and it will only look for it when you submit the form. Since every time you submit the form, it is going to the execute method, the validation will occur every time you submit the form.
Also, if you are extending the ActionSupport class, that class already defines the input() method, so you would not even need to change your action class to accomplish this.

Answer 2

It's possible to do things differently but lets say you let struts2 handle all the requests. Everything that struts2 handles is an "action".
Don't worry about GET or POST they are just two different methods of sending data to an action, if there are parameters (regardless if they are get or set) then struts2 will try to place that data onto the actions class (assuming there is one). If there is a validation method (or a properly named validation xml file) then validation will be run after the class properties are set. Then the execute() method for the class is called (assuming there is a class). After this a jsp is typically rendered which has at its disposal all the public data in the action's method.
Take your "showForm" action... you can reduce the xml to:
<action name="showForm">
<result>inputForm.jsp</result>
</action>
You can see you don't need to define a class. Further the default result is success so we don't need to mention that either.
So when thinking of hmtl we would think in terms of pages. When thinking in struts we think in terms of actions, they only need to be as complicated as necessary. That is if you need to show a form then you need a show form action, if you want a display page that uses the form data then you need a "displayPage" action which does something with the form data.
So think of each action as starting with a url > ----------- > ending with returning date (generally rendering a jsp). The dashes are the optional parts that you may define, but if you don't they will sensibly default for you. To see what features are provided to you you'll need to look in struts2-core-x.x.x.x.jar and view the contents of the struts-default.xml that is where "defaultStack" is defined. Each interceptor in turn is called, knowing what they offer (and the other interceptors offer) let you know what you get out of the box (I wouldn't look into them too deeply just know they are there so you'll know for instance that if you need to upload a file the simple fact that the "fileUpload" intercepter is in the default stack should be indication enough that there must be built in file uploading capabilities.
So no there is not a "false action" to the input form. It is a real action abet a simple one. After you learn how to define packages, actions, default actions for a package and perhaps globally and learn how to define an interceptor then you should look at the conventions plug in. It makes life a lot easier!

Answer 3

Your question makes sense. Your pattern is correct, though:
as Quaternion pointed out, there is little or no "verbosity". Your first "showForm" is a dummy "action mapping", its "do nothing" class does not need a particular class definition (the default ActionSupport is enough).
there are other possible patterns; some people might prefer the idiom you are pointing out (and it has a long history - I remember doing some pelr CGI pages in that way, centuries ago) : use a single url (and hence a single action mapping) for the two "steps" (show the initial form and process the form), by guessing inside the action method (or in the validator) the current step, perhaps by checking that some parameter is present (perhaps a hidden field) or perhaps by discriminating POST/GET. In Struts2, I prefer the other way, in general.
BTW, calling the Struts2 actions "stateful" is correct only if you undestand (you do, apparently) that that 'state' does not survive among requests.