Imagine a Struts 1.0 world where an ActionForm was absolutely needed even for prototyping 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 beingdeveloped 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 DynaActionForms using XML instead of relying on the application developer to create the Java ActionForms. 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 to prototype navigation instead of 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 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 some reasons why.

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 (Introspection) machinery that can be avoided.
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 I glossed over earlier, which they do best and let us limit them to just that. I use them with caution, only when I absolutely need them.