Different combinations of action and actionform in struts select the blog from sean_gao

See a good article on tss.com about the advantages and disadvantages of different combinations of action and actionform in struts. I will digest it and sort it out for your reference. Original article title: struts action mappings: Divide ET impera, Author: Michael juravlev. URL on the TSS: http://www.theserverside.com/articles/article.tss? L = strutsactionmapping

Note: reading this article requires some struts basics.
Note: The lower-case action in the text does not necessarily represent the specific struts action class, but sometimes it also refers to the overall action mapping.

[1] complete action

<Action Path = "/afullaction"
Type = "somepackage. someactionclass">
Name = "someform"
Input = "somejsp. jsp"
<Forward name = "successful" Path = "somejsp. jsp"/>
<Forward name = "failed" Path = "someotherjsp. jsp"/>
</Action>

First, the struts actionservlet receives a request, and then locates the corresponding mapping according to the configuration of the struts-config.xml ); next, if the form is in the request or cannot be found in the defined range, create a new form instance. After obtaining the form instance, call its reset () method, then, put the parameters in the form into the form. If the validate attribute is not false, call the validate () method. If validate () returns non-empty actionerrors, the URI specified by the INPUT attribute will be transferred. If an empty actionerrors is returned, execute () method of the action to determine the target URI Based on the returned actionforward.

The result is that execute () is executed only after validate () is successful. The INPUT attribute specifies a URI.

[2] only form actions

<Action Path = "/aformonlyaction"
Type = "org. Apache. Struts. Actions. forwardaction"
Name = "someform"
Input = "somejsp. jsp"
Parameter = "someotherjsp. jsp"
/>

First, Struts searches for someform in the defined scope. If it finds it, It is reused. If it cannot find it, a new instance is created. After obtaining the form instance, it calls its reset () method, then, put the parameters in the form into the form. If the validate attribute is not false, call the validate () method. If validate () returns non-empty actionerrors, the URI specified by the input property will be transferred. If an empty actionerrors is returned, the URI specified by the parameter property will be transferred.

The result is that no action class can store our business logic, so all the logic to be written can only be written to the form reset () or validate () method. Validate () is used to verify and access the business layer. Because the action ing here does not include forward (and it doesn't make sense), you can only use the default forward instead of redirection. This form-only action can be used to process data acquisition and forward to another JSP for display.

[3] only action

<Action Path = "/anactiononlyaction"
Type = "somepackage. someactionclass">
Input = "somejsp. jsp"
<Forward name = "successful" Path = "somejsp. jsp"/>
<Forward name = "failed" Path = "someotherjsp. jsp"/>
</Action>

First, after receiving the request, the actionservlet obtains the action class instance and calls the execute () method. Then, based on the returned actionforward, it finds forward in the configuration and forward to the specified URI or action.

The result is that no form instance is passed in the execute () method, so execute () must obtain parameters from the request. Actions can be forwarded or redirected. Such actions cannot process requests submitted through HTML form, but can only process link requests.

[4] JSP-only actions

<Action Path = "/ajpoliclyaction"
Type = "org. Apache. Struts. Actions. forwardaction"
Parameter = "someotherjsp. jsp"
/>

First, the actionservlet calls the execute () method of forwardaction after receiving the request. Execute () will forward to the URI according to the configured parameter attribute value.

The result is that no form is instantiated. The more realistic situation may be that form is defined in the scope of higher request level; or this action is used as a system parameter after the application is compiled. You only need to change this configuration file without re-compiling the system.

[5] Two actions correspond to one form

<Action Path = "/anaction"
Type = "somepackage. someactionclass">
Name = "someform"
Input = "somejsp. jsp"
<Forward name = "successful" Path = "/anotheraction. Do"/>
</Action>
<Action Path = "/anotheraction"
Type = "somepackage. someotheractionclass">
Name = "someform"
Input = "someotherjsp. jsp"
<Forward name = "successful" Path = "someresultjsp. jsp"/>
</Action>

For each separate action, there is no substantial difference between processing and complete action. This combination mode can be used to pass the form object ). Note that the reset () and validate () Methods of form are also called in the next action. Therefore, we must ensure that the information in Form is not overwritten.

The processing method is roughly divided into two types: a) Put an indicator in the request to indicate that the previous action intends to pass the form to the next action, so that the value of the form can be retained in the next action, this method can only be used when forward is used. B) when using Redirect instead of forward, you can place the indicator at the session level or higher and clear the indicator at the last part of the command chain.

[6] Two actions correspond to two forms

<Action Path = "/anaction"
Type = "somepackage. someactionclass">
Name = "someform"
Input = "somejsp. jsp"
<Forward name = "successful" Path = "/anotheraction. Do" Redirect = "true"/>
</Action>
<Action Path = "/anotheraction"
Type = "somepackage. someotheractionclass">"
Name = "someotherform"
Input = "someotherjsp. jsp"
<Forward name = "successful" Path = "someresultjsp. jsp"/>
</Action>

This combination method is similar to the previous one in the process, but we now provide form for the two actions separately, so the code looks clearer. Therefore, we can process the inputs and outputs of Web applications separately. It is worth noting that the next action will also try to write those parameters to the form, but we can do this: a) use another set of attribute names in the next form; B) only getter is provided, not setter.

The general solution is as follows:
The previous action receives input, verification, and then writes data to the business layer or persistent layer, redirects it to the next action, and the latter action manually extracts data from the business layer/persistent layer, write form (in other ways) to the front-end JSP display.

The advantage of this is that you do not have to retain the value in the input form, so you can use redirect instead of forward. This reduces the coupling between two actions and avoids unnecessary repeated submissions.