XDoclet works great with DynaForms. Here's a link to a doc I wrote about it:
http://www.systemmobile.com/articles/XDocletDynaForms.html On Mon, 21 Feb 2005 12:09:14 -0500, Benedict, Paul C <[EMAIL PROTECTED]> wrote: > Any other takers? If any Struts committers have opinions, please share them. > > Also, how well does Xdoclet work with dyna forms? > > -----Original Message----- > From: Erik Weber [mailto:[EMAIL PROTECTED] > Sent: Monday, February 21, 2005 11:49 AM > To: Struts Users Mailing List > Subject: Re: ActionForm vs. DynaActionForm > > I didn't mean "better than either one". I meant "better than building > your own ActionForm by hand", and thus better than using Dyna form. > > Erik > > Erik Weber wrote: > > > Wouldn't a parser handler that could build an ActionForm skeleton > > during a parse of a form JSP be better than either one? > > > > Erik > > > > > > Hubert Rabago wrote: > > > >> 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]
