Problems with DynaActionForm

Why should we not use DynaActionForm:

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)


Rishi Kant Sharma(Software Engineer)
Contact No: 9818184605
Email: rishi.sharma@interglobetechnologies.com