WebWork Learn to configure action, result, and interceptor

Original source: http://www.blogjava.net/crespo9907/archive/2007/03/10/webworkinaction_note3.html, reproduced please keep.

first, the core of action absolutely

In practice the action is always an extended Com.opensymphony.xwork.ActionSupport Java class, or always inherits Actionsupport (direct or indirect). We can know in the HelloWorld program of the last note that WebWork is calling action after parsing a specific URL form by Servlet-dispatcher (the new version has been changed to the filter implementation) after receiving the HTTP request. The Execute () method of the HelloWorld class is called as a URL request for the/hello.action style.

The minimum information required to configure an action is the action name and the corresponding action class. When they are added to the Xwork.xml file, a mapping of the action is established. Or list one of the most concise examples: Map the action name login to the login class.
1 <! DOCTYPE xwork Public "-//opensymphony group//xwork 1.1.1//en"
2 "HTTP://WWW.OPENSYMPHONY.COM/XWORK/XWORK-1.1.1.DTD" >
3
4 < Xwork >
5 <!--Configuration for the default package. -
6 < Package name = "Default" >
7 < Action name = "Login" class = "Com.wwinaction.webapp.actions.users.Login"/>
8 </Package >
9 </xwork >

The action tag in the code above is self-enclosing, and you'll think it's useless. Indeed, an action without result information has no practical effect except in the rare case of using <ww:action/> tags. Fortunately, WebWork has built-in almost all of the commonly used result types, but you can also create custom result types (which are described in detail later in the notes). Let's now add result to the above configuration and make it an action that can actually be used in practice.
1 <! DOCTYPE xwork Public "-//opensymphony group//xwork 1.1.1//en"
2 "HTTP://WWW.OPENSYMPHONY.COM/XWORK/XWORK-1.1.1.DTD" >
3
4 < Xwork >
5 <!--Include WebWork defaults--
6 < include file = "Webwork-default.xml"/>
7
8 <!--Configuration for the default package. -
9 < Package name = "Default" extends = "Webwork-default" >
< Default-interceptor-ref name = "Defaultstack"/>
One < action name = "Login" class = "Com.wwinaction.webapp.actions.users.Login" >
< result name = "Input" > login.jsp </result >
< result name = "Success" type= "redirect" >/secure/dashboard.action </result >
</Action >
</Package >
</xwork >

Comparing the two examples above, there are two important changes: the introduction of Webwork-default.xml and the addition of two result nodes. Each result has a name, an optional type, and a specific value. The default result type of the package or superpackage is used when no type is specified. In this case, the dispatcher (dispatcher) is defined in the Webwork-default.xml file.

In the example above, if the returned result code is success then the user will be redirected to/secure/dashboard.action (this is another action, which is not currently defined, we will ignore it). If the return as input browser displays login.jsp here, and the information that the user has just entered is still there, because the type is the default dispatcher, the action will continue to pass the parameter value to login.jsp. Note The result mapping can be either an absolute path or a relative path. This will be very important when discussing the concept of namespace.

Let's talk about providing an alias for the action. Each action node in the configuration is an action map, but you can also map multiple names to the same action class. WebWork is a framework that implements the generalization command pattern. By default, WebWork invokes the Execute () method of the action class. But you can also specify which method the webwork should call by adding an optional methods property to the action map. However, the specified method must have the same "shape" as the Execute () method, which means that there is no input parameter, returns a string type of result code and has a selective throw exception. An example is given below:

1 < action name = "users" class = "com.wwinaction.webapp.actions.users.UserAction" >
2 < result name = "Success" >/web-inf/pages/userlist.jsp </result >
3 </Action >
4
5 < action name = "Edituser" class = "com.wwinaction.webapp.actions.users.UserAction" method = "Edit" >
6 < result name = "Success" >/web-inf/pages/userform.jsp </result >
7 < result name = "Input" >/web-inf/pages/userlist.jsp </result >
8 </Action >
9
< action name = "Editprofile" class = "com.wwinaction.webapp.actions.users.UserAction" method = "Edit" >
< result name = "Success" >/web-inf/pages/userform.jsp </result >
< result name = "Error" >/web-inf/pages/mainmenu.jsp </result >
</Action >

Three actions are associated to the Useraction class, the first executes the default execute () method, and the second two executes the edit () method. (Note: WebWork mapping to methods through Xwork.xml has two mechanisms: by looking for methods that are consistent with the method attribute value, by looking for methods in the form of Domethod (). This is intended to be compatible with older versions, because some words are Java keywords that cannot be used as method names, such as default. At this point, the method name is written as the Dodefault,method value of default can also work. But the last time I saw the struts document found WebWork2 migrated to Struts2 after the cancellation of this mechanism, it is recommended that you do not use. There is one more trick to note: The last two action mappings are the same method, but two different sets of result are configured, which is one of the benefits of the action alias.

WebWork also has a handy alias syntax that does not need to be configured, and supports maps that are name!method.action-shaped. As in the example above, users!edit.action is mapped to the edit () method. This syntax can be turned on or off by setting in Struts2.

Attached STRUTS2 Related resources:
Some differences between WEBWORK2 and Struts2 http://struts.apache.org/2.x/docs/key-changes-from-webwork-2.html
WebWork2 how to migrate to Struts2 http://struts.apache.org/2.x/docs/webwork-2-migration-strategies.html

We can also customize the action by using the <param> tag to parameterize the action. For example, if you have already written an action to handle a Web service request, you may now need to bind different instances of the action to different URLs, and you may also create a separate timeout value for each action. With <param> tags you can use the same Webserviceaction class to implement your ideas.
1 < action name = "Service1" class = "com.example.WebServiceAction" >
2 < result name = "Success" >/success.jsp </result >
3 < param name = "url" > http://somesite.com/service.wsdl </param >
4 < param name = "Timeout" > </param >
5 </Action >
6
7 < Action name = "Service2" class = "com.example.WebServiceAction" >
8 < result name = "Success" >/success.jsp </result >
9 < param name = "url" > http://somesite.com/service2.wsdl </param >
< param NAME = "Timeout" > </param >
One </action >

1 public class Webserviceaction {
2 private String URL;
3 private long timeout;
4
5 public void SetUrl (String URL) {
6 this.url = URL;
7}
8
9 public void SetTimeout (long timeout) {
10</