Again, sharing my opinion on his points with you guys. * "The DynaActionForm bloats up the Struts config file with the xml based definition. This gets annoying as the Struts Config file grow larger."
I use FormDef, so this isn't a problem for me. * "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." ActionForm fields intended to hold form values are expected to use Strings, and I still haven't had a reason to do otherwise. If you get a typo after your change and have to redeploy, well I don't mind living with that. It's not like its going to happen often enough to seriously make me prefer adding class after class after class containing only string-ified version of existing business objects. * "ActionForm can be cleanly organized in packages as against the flat organization in the Struts Config file." I organize my action forms with the actions they interact with. I don't have submodules, but I still have a struts-config-group1.xml and struts-config-group2.xml, each of which correspond to functions and features I've grouped together, each containing only the declarations relevant to that group. * "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(“..”)." DynaForms still act as the firewall. I can still pass around my DynaForm to other objects without passing the request object. DynaForms provide much more than request.getParameter, especially when matched with Validator, and it still has built-in support from Struts. * "DynaActionForm construction at runtime requires a lot of Java Reflection (Introspection) machinery that can be avoided." The cost of this has been disputed several times. I haven't seen any numbers, so I can't say for sure how big or small the cost is, but I haven't heard of a single case where a web app's performance was made considerably better by reducing reflection operations after a form submission. Design changes are more likely to make a significant performance boost. Besides, the reflection-heavy BeanUtils methods are used for both DynaForms and ActionForm classes, so I'm not sure where the savings, if any, will be. * "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)" The issue isn't just with setters and getters. You'll be adding a whole class everytime you need a form. Especially when you plug in something like FormDef, I'm not sure why you'd choose a regular ActionForm for most CRUD forms. Hubert --- Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Eric, > > perhaps this is useful for you. > http://weblogs.java.net/pub/wlg/964 > > cheers, > matthias > > > -----Original Message----- > > From: Eric Noel [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 04, 2004 7:35 AM > > To: Struts Users Mailing List > > Subject: Struts 1.1 ActionForm > > > > > > What is now the recommend technique for ActionForm, do we > > still have to > > use them? or just make use of the DynaActionForm instead and > > then create > > the corresponding Action or LookupDispatchAction? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
