Sleepless in Tucson - The Diigo Meta page

• 22 Nov 06
  

  Kuba Nowak

  j2ee java struts

  •   DynaActionForms:
    
    DynaActionForms are universally loved and hated. In teaching, consulting Struts and developing with Struts, I have found that DynaActionForms are either embraced or rejected. The idea behind DynaActionForms is that instead of creating an ActionForm per form, you instead configure an ActionForm per form.
    
    Advantages:
    Some folks feel creating an ActionForm class for each HTML form in your Struts application is time-consuming, causes maintenance problems, and is frustrating. With DynaActionForm classes you don’t have to create an ActionForm subclass for each form and a bean property for each field. Instead you configure an DynaActionForm its properties, type, and defaults in the Struts configuration file.
    
    Deltas :
    You still have to create the DynaActionForm in the struts configuration file. When you use the DynaActionForm, you have to cast all the properties to their known type. Using a DynaActionForm is a lot like using a HashMap. In your Action if you are accessing a DynaActionForm, if you screw up a property name (misspell it) the compiler will not pick it up, instead you will get a runtime exception. If you cast an Integer to a Float by mistake the compiler will not pick it up, you will get a runtime exception. DynaActionForms are not type safe. If you use an IDE, code completion does not work with DynaActionForms. If you override the reset method, you defeat the purpose of having a DynaActionForm. Another point is that DynaActionForms are not very dynamic, as you still have to change the configuration file, and then restart the web application to get Struts to recognize an additional field.
    
    TIP: As you can probably tell, I think using DyanActionForms is less than ideal. I feel DynaActionForms are not really dynamic at all since you have to restart the web application when you change them. I find them no more dynamic than using Java classes. I prefer to create my ActionForms by subclassing ActionForm and using bean properties. I find that modern IDEs make short work of adding JavaBean properties. I see no real advantage to using DynaActionForms over ActionForms. If I want to make an ActionForm dynamic, I add a mapped backed property. I have worked on projects that forced DynaActionForms. I much prefer regular ActionForms.

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.