Learning the New Jakarta Struts 1.1, Part 1
Pages: 1, 2
DynaActionForms provide a convenient mechanism that eliminates the need to write
ActionForms at all.
DynaActionForm allows for form properties to be dynamic. What this means is that you can define properties in your struts-config.xml file and set the type of the form to be
org.apache.struts.action.DynaActionForm. Nothing more needs to be written.
DynaActionForms accomplish this by making use of the
DynaBean provided in the Apache Commons project. This dynamic behavior is provided through reflection and Hashmaps.
DynaActionForm is defined in the struts-config.xml using the
<form-property> elements as follows:
<form-bean name="insertDynaForm" type="org.apache.struts.action.DynaActionForm"> <form-property name="artist" type="java.lang.String"/> <form-property name="title" type="java.lang.String"/> <form-property name="genre" initial=”Dance” type="java.lang.String"/> </form-bean>
The attributes of a dynamic form are similar to those of a standard
ActionForm. The name is used to reference this form bean in Actions, and the type specifies the class to be instantiated. When using the
DynaActionForm class, the dynamic attribute of the
<form-bean> automatically defaults to true. For a
DynaActionForm, you specify all of the properties of the form by using the
<form-property> element. The name is the property name. The type is the
fully qualified Java class name of the implementation class of this bean property. If this is an indexed property, you can follow the type with
. You’ll notice that in the last
<form-property> defining the genre property, we are setting the initial (or default) value to be "Dance." This value is also used when the
reset() method is called on a
DynaActionForm, and allows for a mechanism to specify default values on the form. If nothing is specified in the initial attribute, then all primitive types are set to zero, while Objects are set to null.
It can be very convenient to use
DynaActionForm. One of the main advantages is that you have to write less code. What we just defined in the code sample above is all that's required to use the form just like any other form. The one issue to be aware of is validation. When using
DynaActionForm, there is an assumption that validation is handled someplace other than the
ActionForm. It is possible to implement validation within your Action itself, but there is a better approach.
To do validation, you can use the
DynaValidatorActionForm, which are both found in the
org.apache.struts.validator package. By extending the
DynaActionForm, basic field validation can be provided, based on an XML file. Validation is based on the key passed into the validator. This key is the name attribute from the struts-config.xml file. This should match the form's elements name attribute in the validation.xml file.
Multiple Application Support
It is possible in Struts 1.1 to have multiple sub-applications defined and supported. What this means is that you can break your application into various sub-applications for better maintenance. You no longer have to camp outside of the person’s cube who has the one and only struts-config.xml file checked out of source control.
Another reason to consider using sub-applications is for control flow that varies by client. In some applications, you may have a standard set of pages, but the control flow may vary depending on what client logs into the application. You could store this control flow metadata into a database and generate the web.xml file (or portions thereof), along with all of the various struts-config.xml files.
If you ever worked with Struts 1.x, you probably noticed that many of the elements defined in the web.xml file have been moved to the struts-config.xml file in Struts 1.1. This is because they are now application-specific. Multiple sub-applications are identified by a prefix at the beginning of the context-relative portion of the request URI. If no application prefix can be matched, the default configuration is selected. The default has a prefix equal to a zero-length string. Implementing the default this way allows for backward compatibility with Struts 1.0.x, where it was possible to only have one application defined.
If you have a large-scale application that contains different functional areas, then it would make sense to consider having sub-applications that work together instead of one big application. The web.xml file below shows how sub-applications can be defined.
<!-- The default sub-application --> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <!-- The catalog sub-application --> <init-param> <!-- catalog prefix --> <param-name>config/catalog</param-name> <param-value>/WEB-INF/struts-config-catalog.xml</param-value> </init-param> <!-- The sorter sub-application --> <init-param> <!—sorter prefix --> <param-name>config/sorter</param-name> <param-value>/WEB-INF/struts-config-sorter.xml</param-value> </init-param>
When using sub-applications, you might define the context-relative request URIs to specify which sub-app to use. For example, the action on a form might appear as:
<html:form action="/logon" >
which refers to the default sub-application or
<html:form action="/catalog/listCds" >
which refers to the action class in the catalog sub-application. You don’t actually have to do this. You can use
/listCds if you want, within the catalog sub-application. The basic rule is this: all struts-config.xml parameters that were context-relative in 1.0 are now sub-app-prefix-relative in 1.1. That way, a single application can be used as either the default sub-application, or as a named sub-application with no change.
Read more JSP and Servlets columns.
Return to ONJava.com.