Well, I certainly won't be able to list them all. The one I came across is a complex structure. True, DynaActionForms can support really complex structures, and this is especially true when using Niall's Lazy*Forms. However, the learning curve and maintenance can get complex as well. Mine had multiple levels of lists and mapped values. Coupled with the complex validation rules we had to apply, I just chose to use custom ActionForm classes. I felt this made it easier for me and for teammates of mine who weren't as familiar with Struts as I was.
Hubert On Mon, 21 Feb 2005 11:38:24 -0500, Benedict, Paul C <[EMAIL PROTECTED]> wrote: > Hubert, > > >> I've had apps where I had > more ActionForm subclasses than DynaActionForm, and this was due to > requirements that DynaActionForms simply couldn't handle. > > If possible, please explain when dyna forms do not meet requirements. I am > very interested in knowing their limitations, as I already know their > benefits. > > Thanks, > Paul > > -----Original Message----- > From: Hubert Rabago [mailto:[EMAIL PROTECTED] > Sent: Monday, February 21, 2005 11:33 AM > To: Struts Users Mailing List > Subject: Re: ActionForm vs. DynaActionForm > > I really would not give too much weight to the blog you linked to. If > you've read the comments of the readers, you'd see that some of his > arguments aren't really that strong, and some are even totally > incorrect. > > Personally, I use DynaActionForm for each form that it can support. > Once I have a form with needs that a DynaActionForm can't fulfill, > that's when I decide to use ActionForms. I've had apps where I had > more ActionForm subclasses than DynaActionForm, and this was due to > requirements that DynaActionForms simply couldn't handle. Still, my > first choice would be a DynaActionForm when possible. Pre 1.1, I've > had an app where it was form bean after form bean after form bean. I > got tired of it that for some forms, I just used plain HTML without > Struts tags/form beans. I don't want to go back to that again. > > Maybe I shouldn't say anything since I haven't done any JSF yet, but > solely from my impressions of what I've read so far: I think the > concept of JSF's backing beans are different from Struts' ActionForms. > I think JSF's overall approach is different from Struts, that the > differences are greater than the similarities. Whether ActionForms or > DynaActionForms is more similar to JSF's backing beans shouldn't > affect your decision, since you're using Struts, not JSF. Applying > the models of one framework to another when their approaches and > principles, as well as their underlying support, are different, just > sounds dangerous. > > As for compile time type information, well, Strings are Strings > whether you use one or the other. > > http://marc.theaimsgroup.com/?l=struts-user&m=109767197521860&w=2 > > On Mon, 21 Feb 2005 11:03:41 -0500, Benedict, Paul C > <[EMAIL PROTECTED]> wrote: > > What are the advantages and disadvantages of choosing ActionForm vs. > > DynaActionForm? > > > > I ask this because I always found DynaActionForm to be more valuable ... > > until a co-worker picked my brain. He did not like the lack of type > > information at compile time. I agreed. Also, I don't know how well > > DynaActionForms work with AOP ala Xdoclet. Furthermore, JSF uses "backing > > beans" which are real beans, and they more resemble ActionForm objects > than > > the latter. > > > > I have read this article too: > > http://weblogs.java.net/blog/srikanth/archive/2004/01/actionform_or_d.html > > > <http://weblogs.java.net/blog/srikanth/archive/2004/01/actionform_or_d.html> > > > > Does anyone have any professional opinions and experience on this matter? > > > > Thank you, > > Paul > > > > > ---------------------------------------------------------------------------- > -- > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New > Jersey, USA 08889), and/or its affiliates (which may be known outside the > United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as > Banyu) that may be confidential, proprietary copyrighted and/or legally > privileged. It is intended solely for the use of the individual or entity > named on this message. If you are not the intended recipient, and have > received this message in error, please notify us immediately by reply e-mail > and then delete it from your system. > > > ---------------------------------------------------------------------------- > -- > > > > --------------------------------------------------------------------- > > 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] > > ------------------------------------------------------------------------------ > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New > Jersey, USA 08889), and/or its affiliates (which may be known outside the > United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as > Banyu) that may be confidential, proprietary copyrighted and/or legally > privileged. It is intended solely for the use of the individual or entity > named on this message. If you are not the intended recipient, and have > received this message in error, please notify us immediately by reply e-mail > and then delete it from your system. > ------------------------------------------------------------------------------ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
