Struts.xml configuration file

The 3rd chapter of "Mastering struts2:web2.0 Development" is outlined in the 2nd chapter, where we outline the elements required for a basic Web application. These knowledge points will be expanded in this chapter to facilitate an overall understanding of struts 2. This section introduces you to the Struts.xml configuration file.

AD:

3.3.3 struts.xml configuration file (4)

7. Action

The configuration of the action is similar to the information provided by the annotation configuration, but the XML configuration has a richer selection of optional configuration options.

Note Be careful when using both the XML configuration and the annotation configuration for the same action. If the XML configuration references a namespace and the action name is the same as the name used in the comment, the annotation configuration takes precedence and ignores the XML configuration. This can lead to some confusing error messages.

The XML configuration differs from the annotation configuration in that it allows you to set the action to the default action for a package. The servlet engine typically returns an HTTP 404 error when the user enters a URL that is not mapped to the action. To avoid this output interface, we can use the DEFAULT-ACTION-REF tag to specify that an action is the default, so that when no other mappings are able to respond to the URL, the default action is executed. In the action mapping example below, the default action is Testme:

Unlike the 0 configuration options, when using XML configuration, the namespace of the action is typically determined by the namespace of the package it is in. Additional configuration elements are required to specify the implementation class name of the action (through the class attribute) and the name of the action (via the Name property). Note there is not enough flexibility to provide a name for the action. Note Another property that cannot be set is method, which specifies how the request logic is handled in action, so that the same action class can have different action configurations so that different configurations can invoke different methods in the class.

We have explained these tags in the previous article, and they are configured exactly the same way.

Result Label: Under Action, you can have multiple result labels, and the result label can configure different outputs for different requests. If the Name property is ignored, its value is success, and if the Type property is omitted, its value is the default result type (the default result type should be a dispatcher if not modified).

Interceptor-ref tag: Specifies an interceptor for the current action in place of the default interceptor reference configured in the package.

Exception-mapping tag: You can provide a local exception map at the action level (it will be processed before the global exception map), and the result property of this tag can be the results of the current action, or it can be a global result.

PARAM Tags: transfer static values to action via XML configuration.

Tip param tags are not only used in action, interceptor, and interceptor-ref tags, but also in Result-type, Default-interceptor-ref, Default-action-ref, The param is used in the label body of the result and exception-mapping tags. In most environments, param tags can play a greater role when used in action and interceptors.

8. Wildcard Configuration

In the process of developing your application, you are likely to encounter pattern problems in configuration, such as when the package name and the URL that is used to invoke the action (such as/app/admin/user/add.action and/app/sales/user/ Edit.action), such as when the name of an action contains a domain name or a method called in the action class, such as/app/adduser.action and/app/edituser. Action).

When this pattern-matching problem occurs, an alternative approach can be used. This approach eliminates the need to explicitly configure each action because it is too time-consuming for those large applications, and we can use wildcards to combine configurations into a single action configuration. You can use the asterisk as a wildcard for the action Name property, and each asterisk can be retrieved separately using the number in parentheses (starting at index 1).

For example, a Web app URL contains a standard web context, followed by an entity object name, and ends with an action. Examples of this model are:/app/user/add.action,/app/user/edit.action,/app/project/add.action, and/app/project/edit.action. The standard also specifies that each entity object has an action class, and that the action class has multiple methods to handle the interaction with the user interface (such as the edit () and add () methods, and so on).

Using wildcard characters, this pattern can be configured for all entity objects in one configuration:

You can use the entered URL to determine the class name and the method name. When the URL is/app/user/add.action, the class name is Com.fdar.apress.s2.userAction, and the method name is add (note that the character case in the URL matches the class name).

Wildcard characters can also be used to extend the result label. For/app/user/add.action this URL, "Success" result will render/user/add.jsp page, "input" result renders/user/edit.jsp, "home" renders/user/home.jsp.

The only restriction to using wildcards in the Name property of an action is that you cannot put two asterisks together without separating them. If so, the Struts 2 framework will not know how to separate the name of the action. Therefore, you need to use a delimiter, such as "/" can be used (the previous example is to use the symbol) or use "_" symbol, such as the/app/user_edit.action URL.

If you need a non-word (untokenized) URL, we can use this special accessor for {0}.

Note If you do need to use a slash in the action's name, such as Name= "*/*", then you need to set the value of the Environment property struts.enable.SlashesInActionNames to True.