DynaActionForm - The Dynamic ActionForm


DynaActionForm ‚ The Dynamic ActionForm

Struts 1.0 mandated that every HTML form in the JSPs have an associated ActionForm. Struts 1.1 changed all that with the introduction of DynaActionForm ‚ dynamic ActionForm as the name suggests. DynaActionForm is defined in the struts-config.xml as a form-bean. A sample DynaActionForm is shown in Listing 5.4.

Listing 5.4: Sample DynaActionForm
 <form-bean  name="CustomerForm"             type="org.apache.struts.action.DynaActionForm">     <form-property name="firstName" type="java.lang.String "/>     <form-property  name="lastName" type="java.lang.String                                                 initial="Doe"/> </form-bean> 
 

There are two major differences between a regular ActionForm and a DynaActionForm .

  1. For a DynaActionForm , the type attribute of the form-bean is always org.apache.struts.action.DynaActionForm .

  2. A regular ActionForm is developed in Java and declared in the struts-config.xml . The JavaBeans properties of a regular ActionForm are created by first defining the instance variable and then adding a getter and setter for that instance variable. A DynaActionForm has no associated Java class. Its JavaBeans properties are created by adding the < form-property > tag in Struts Config file (and also declaring its Java type). In Listing 5.4, CustomerForm is declared as a DynaActionForm with two JavaBeans properties ‚ firstName and lastName. The type attribute of the < form-property > is the fully qualified Java class name for that JavaBeans property; it cannot be a primitive. For instance int is not allowed. Instead you should use java.lang.Integer . You can also initialize the form-property , so that the html form shows up with an initial value.

How about an example of using DynaActionForm? Remember, the Hello World application from Chapter 3. Well, now let us rewrite that example using DynaActionForm. You will be surprised how easy it is.

The first step obviously is to develop the DynaActionForm itself. Listing 5.4 is the DynaActionForm version of the CustomerForm from Chapter 3. The < form-property > tags are the equivalent of the JavaBeans properties of the ActionForm.

What about the validate() method? In Chapter 3, you were able to code the validate() method since you had the CustomerForm as a Java class. What about the DynaActionForm? With DynaActionForm, unfortunately this is not possible. Don ‚ t be disappointed. You can use the DynaValidatorForm (a subclass of DynaActionForm ) in concert with Validator Plugin. We will cover this topic in the next section.

Rearranging the execute() method in CustomerAction is the second and the final step in ActionForm to DynaActionForm conversion. Listing 5.5 shows the CustomerAction . Compare this with the CustomerAction in Chapter 3 (Listing 3.5). Instead of using compile time checked getters and setters, the JavaBeans properties in DynaActionForm as accessed just like HashMap .

Listing 5.5: CustomerAction ‚ Action Bean for App1
 public class CustomerAction extends Action {     public ActionForward execute(ActionMapping mapping,                              ActionForm form,                                   HttpServletRequest request,                              HttpServletResponse response)                                   throws Exception     {         if (isCancelled(request)) {            System.out.println(Cancel Operation Performed");            return mapping.findForward("mainpage");         }         DynaActionForm custForm = (DynaActionForm) form;         String firstName = (String) custForm.get("firstName");         String lastName = (String) custForm.get("lastName");         System.out.println("Customer First name is " +                                         firstName);         System.out.println("Customer Last name is " +                                          lastName);         ActionForward forward = mapping.findForward("success");         return forward;     } } 
 

One thing is obvious. The DynaActionForm is quick and easy. It is very convenient for rapid prototyping. Imagine a Struts 1.0 world where an ActionForm was absolutely needed to prototype an HTML form in JSP using Struts custom tags. Things were good until the separation of concern came into picture. In real life projects, different people play different roles. Application developers have the responsibility of developing Java code and page authors would exclusively prototype the page and its navigation using JSP markup tags. Since the Java code being developed is constantly changing, the developer does local builds on his machine. Similarly the page author would certainly like to add or remove fields from the prototype during the page design. Since the HTML forms map to ActionForms, the above scenario implies one of two things.

  1. The page author constantly pesters the Java application developer to modify the ActionForm.

  2. The page author develops the ActionForm all by himself.

While the former hampers the developer productivity, the latter leads to overlap of responsibilities and headaches . Both options are not ideal. Struts 1.1 has solved this problem by introducing DynaActionForm . Although originally designed for developer ‚ s ease of use, it has been serving the purpose of role separation in a project very well. One can envision an ideal project development as follows .

A page author can be isolated from the Java application development by having a application server environment available for page design. He develops the JSPs as JSPs using the Struts (and other) custom tags, not just HTML prototypes . He also creates DynaActionForm s using XML instead of relying on the application developer to create the Java ActionForm s. In other words, the page author is isolated from the nitty-gritty ‚ s of the build, deploy and all that chaos accompanying it ‚ at least in the prototype phase.

The page author designs the page Navigation as plain forwards instead of Form submissions; In other words he uses < html:link > to prototype navigation instead of < html:submit >s. In case you are wondering why anybody would go this route, here is the answer: In Struts framework, the presentation logic resides in the Action classes. It is highly unlikely that the presentation logic (Action) for the ActionForm will be ready even before the prototype is ready. Hence the page author uses the < html:link > and ForwardAction to model the navigation. Once the prototype is approved, the application developer works on the presentation logic by developing the Action classes. When doing so, the application developer creates equivalent ActionForms for the existing DynaActionForms, one form at a time. The application developer also replaces the forwards in the JSP with form submissions and adds the glue code in Action classes to handle the form submissions.

Okay, so DynaActionForms are great, why replace them with ActionForms anyway? In my opinion, DynaActionForms are good only in the prototyping stage. Once past that stage, it is always better to have strongly typed ActionForms. Here are some more downsides of using DynaActionForms

  1. The DynaActionForm bloats up the Struts config file with the xml based definition. This gets annoying as the Struts Config file grow larger.

  2. The DynaActionForm is not strongly typed as the ActionForm. This means there is no compile time checking for the form fields. Detecting them at runtime is painful and makes you go through redeployment.

  3. ActionForm can be cleanly organized in packages as against the flat organization in the Struts Config file.

  4. ActionForm were designed to act as a Firewall between HTTP and the Action classes, i.e. isolate and encapsulate the HTTP request parameters from direct use in Actions. With DynaActionForm, the property access is no different than using request.getParameter( ‚“.. ‚½).

  5. DynaActionForm construction at runtime requires a lot of Java Reflection machinery that can be expensive.

  6. Time savings from DynaActionForm is insignificant. It doesn ‚ t take long for today ‚ s IDEs to generate getters and setters for the ActionForm attributes. (Let us say that you made a silly typo in accessing the DynaActionForm properties in the Action instance. It takes less time to generate the getters and setters in the IDE than fixing your Action code and redeploying your web application)

That said, DynaActionForms have an important role to play in the project lifecycle as described earlier, which they do best and let us limit them to just that. Use them with caution, only when you absolutely need them.

DynaValidatorForm

An application specific form can take advantage of XML based validation by virtue of sub classing the ValidatorForm. The XML based dynamic forms can also avail this feature by specifying the type of the form to be DynaValidatorForm as follows:

 <form-bean  name="CustomerForm"             type="org.apache.struts.validator.DynaValidatorForm">     <form-property name="firstName" type="java.lang.String "/>     <form-property  name="lastName" type="java.lang.String                                                 initial="Doe"/> </form-bean> 

DynaValidatorForm is actually a subclass of DynaActionForm. It implements the validate() method much like the ValidatorForm and invokes the Commons Validator. DynaValidatorForm brings the capability of writing XML based validation rules for dynamic forms too.




Struts Survival Guide. Basics to Best Practices
Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)
ISBN: 0974848808
EAN: 2147483647
Year: 2004
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net