Can you elaborate? Do you mean a utility that would parse incoming form values and then map them to my business objects? :)
On Mon, 21 Feb 2005 11:48:33 -0500, Erik Weber <[EMAIL PROTECTED]> wrote: > 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. > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
