Learning Jakarta Struts 1.1 (2)

　 DynaActionForm
　
　 DynaActionForm provides a convenient mechanism that essentially eliminates the need to write an ActionForm. DynaActionForm allows dynamic form properties. This means that you can define properties in your struts-config.xml file and set the form type to org.apache.struts.action.DynaActionForm. Nothing needs to be written. DynaActionForm uses DynaBean from the Apache public project to complete these operations. This dynamic behavior is provided through reflection and hashmaps.
　　
　 DynaActionForm is defined using tags in the struts-config. The attribute name is used to index the form bean in the Action, and type is used to specify the instantiated class. When using class DynaActionForm, the dynamic properties automatically default to true. For DynaActionForm, all properties of the form are specified using elements. The name in the element refers to the attribute name. Type refers to the class name of the Java implementation class of the bean attribute. If this attribute is of index type, add "[ ]" after type. In the above table, you should pay attention to the definition of the last attribute genre. We set the initial value (or default value) to "Dance". This value will also be set as the default value when the reset() method in DynaActionForm is called, and allows a mechanism to set default values ​​in the form. If no value is specified in the initial attribute, then the initial value of all primitive types is set to 0, if it is an object, the initial value is null (empty).
　
　Using DynaActionForm is very convenient. One of the main benefits is that you only need to write very little code. Just like other forms, the preceding code example is all the code you need to use the form. One thing to know is validation. When using DynaActionForm, it is assumed that validation processing is done somewhere, which is somewhat different from ActionForm. You can implement validation in your own Action, but this is a better approach.
　
　For verification, you can use DynaValidatorForm or DynaValidatorActionForm. Both classes are in the org.apache.struts.validator package. By extending DynaActionForm, you can get validation based on basic value fields of XML files. Validation is based on the key entered into the validator. Key is the name attribute from the struts-config.xml file. It should match the name attribute of the form element in the validation.xml file.
　
　Multiple application support
　In Struts 1.1, multiple sub-applications can be defined and supported. This means you can put your application in a sub-application that is more maintainable. You no longer need to detect source control outside of the single struts-config.xml file.
　
Another reason to use subapplications is to change the control flow based on the client. In some applications, you may have some common pages, but the control flow may change depending on the client logging into the application. You can store this control flow metadata in a database and generate a web.xml file (or part of it), along with a different struts-config.xml file.
　
If you have ever developed for Struts 1.x, you may have noticed that many elements in the web.xml file have been moved to the struts-config.xml file of Struts 1.1. This is because now they are application-specific. Multiple sub-applications are identified by the prefix that begins with the relative context portion of the request URI. If no application prefix matches, the default configuration is selected. The default setting has an empty string prefix. This way of implementing default settings is backwards compatible with Struts 1.0.x where only one application may be defined.
　
　If you have a large application that contains different functional modules, it makes more sense to replace one huge application with sub-applications that run together. The file web.xml shown below shows how to define a sub-application.
　　
　　
　　config
　　/WEB-INF/struts-config-config.xml
　　
　
　
　
　　
　　config/catalog
　　/WEB-INF/struts-config-catalog.xml
　
　
　
　
　　
　　config/sorter
　　/WEB- INF/struts-config-sorter.xml
　　　
　　
　　
　 When using sub-applications, you may define context-sensitive request URIs to specify which sub-application is used. For example, an action on a form might look like this:
　　
　　
　 which references the default sub-application, or
　　
　　
　 which refers to the action class of the catalog sub-application. You don't actually have to do this. You can use /listCds in the catalog sub-application if you want to do this. The basic rule is: all struts-config.xml parameters that were context-sensitive in version 1.0 are now sub-application prefix-specific in version 1.1. In this way, a single application can serve as both a default sub-application and a designated sub-application without modification.

The above is the content of learning Jakarta Struts 1.1 (2). For more related articles, please pay attention to the PHP Chinese website (www.php.cn)!