* A DynaActionForm can't be instantiated with a zero-argument constructor. To create one yourself, you have to use the Struts utility methods or use the factory method to copy an existing instance.
* While BeanUtils can see the DynaProperties, other utilities may not. So if you use them with Struts EL or Velocity templates, you have to go through the map method.
* Likewise, any references in your Actions or other Java code must go through the map and pass the property name as a String. (The recommended approach is to transfer the properties to another bean via BeanUtils.)
* Struts doesn't provide a way to define a DynaActionForm "type". If you want to reuse the same DynaActionForm in a different context using a different validation form, you have to give it a different attribute property in the ActionMapping.
* The properties to be accessed via BeanUtils are an either/or proposition. You cannot extend a DynaActionForm with conventional properties; it checks the DynaProperties and stops. =:(
* Since you you can't mix helper properties in with data-input properties, if the input needs to be massaged, you may need to put helper properties on a separate bean (which might incorporate the DynaActionForm through composition).
The major advantage is that between the Struts Validator and DynaActionForms, you can prototype a good deal of the presentation layer without writing a line of Java code. Likewise, a greater number of changes can be made without compiling Java classes. (Heck, with something like Struts BSF <http://www.twdata.org/struts-bsf/>, you might be able to do some applications with any custom Java code whatsoever).
Politically, DynaActionForms also sit well with people who already have business beans with the same sort of properties found on the formbeans. While you still need to maintain the property names in two places, maintaining one in XML seems less redundant.
For a new project, I would probably suggest starting with DynaActionForms and using a conventional ActionForm only when any of the disadvantages prove to be a problem. Of course, you can mix both approaches and use one or the other as the use-case dictates.
-Ted.
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
