Actually JBuilder comes with a tool for bean generation but I find its a bit like using a sledgehammer to crack a nut for the relatively small forms I am using (a lot have only 2 or 3 properties I need to track with 8 probably being a good average!).
As for productivity , Ive always considered number of lines written to be an inverse measure of it! ;-) (Which makes some of my 1000+ line abstract-uber-classes look rather alarming. (hehe a good 30% is probably null checking and exception handling though!) -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 11:07 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: DynaActionForm Advantages On Tue, 9 Jul 2002, Andrew Hill wrote: > Date: Tue, 9 Jul 2002 10:47:46 +0800 > From: Andrew Hill <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: DynaActionForm Advantages > > I do my rendering using DOM and server side java code. While a lot of it is > now done in abstract superclasses (making use of PropertyUtils to get stuff > from the form) a lot is also still making direct use of specific > actionForms, and I find having real methods in my action form is useful in > catching typos at compile time, That's actually a quite valid reason. > and also means JBuilder (shame on me for not > using vi!) e-macs! e-macs! e-macs! :-) > gives me nice drop down boxes with all the method names, which is > rather useful since my brain's small cache can't remember more than half the > fields on a given form at any one time... > > Furthermore , one can spend ages typing all the getters and setters with > ones brain in nuetral yet still feel one has been getting work done ;-) > Especially if your productivity is measured by lines of code produced :-). It's also feasible to auto-generate form beans with tools of various sorts, which reduces this sort of tedium a lot. > (On the other hand once I make time to actually learn the syntax for > DynaForms I will probably be switching ...) > > Craig > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 06:40 > To: Struts Users Mailing List > Subject: Re: DynaActionForm Advantages > > > > > On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote: > > > > > Tell me again why I should use the standard form beans? > > > > > > I'm trying to understand because it seems to add complexity having two > > different ways of doing Form Beans. Why not polish up the Dyna bean stuff > > and then dump (er, deprecate) normal Form Beans? > > > > If DynaActionForm had been around from the very beginning, I doubt we > would have ever invented the standard ActionForm bean approach. At the > same time, I can't necessarily justify deprecating something that 100% of > existing 1.0 applications are required to use, especially when the rest of > Struts doesn't care at all which way you do things -- and you can even > make your Actions not care if you use PropertyUtils methods to get and set > the property values. > > > One advantage I will give the normal Form Beans is that they are easier > for > > a newbie to pick up and learn. They shorten the learning curve to get > > productive with Struts initially. But if DynaBeans were made to be very > > easy, then this advantage may disappear as well. > > > > It's also a little premature to conclude that DynaActionForm beans are > good replacements for all scenarios where standard ActionForm beans are > currently used - at least in a 1.1 time frame. We need more real world > experience with them to validate this first. > > > > > > > Kevin > > > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
