Mark, Perhaps I am getting old, but the meaning of your metaphors went over my head. On the other hand, this is an international audience.
What is a chocolate fire guard? Do you believe it is harder or easier to use DynaActionForms instead of Strings? Is taking the piss a bit a good thing or a bad thing? Thank you, Ed ----- Original Message ----- From: "Mark Lowe" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, December 17, 2003 10:33 AM Subject: Re: Newbie: java.lang.boolean and DynaActionForm? > No one's suggesting that anyone hangs them selves or that struts isn't > good. But the fact that this list sees a high influx of newbies, > getting battered with high-brow design concepts which while are very > interesting have a certain chocolate fire guard quality to them . > > Easiest thing is to make all the form properties strings, or like has > been suggested, non primitives. It was certainly the case a few months > ago that to use dynaaction forms then it was just less bother to use > strings. > > Sure nesting model objects in action forms does take the piss a bit, > but its nothing that cant be sorted when clients/non tech bosses have > stopped wetting themselves about image swaps.. > > Cheers Mark > > On 17 Dec 2003, at 15:27, Robert Taylor wrote: > > > To address the "fundemental" question, it is considered a "best > > practice" > > to only use String or Boolean objects or collections of String and/or > > Boolean objects or collection of > > data structures which contain String and/or Boolean objects in your > > forms. > > This is because it gives you > > more control over validation. This doesn't mean that DynaActionForms or > > any DynaXXXXForm for that matter doesn't support non-string types. It > > supports > > any Object because essentially the DynaXXXForms internal data > > structure is a > > Map. > > > > In general the Struts form should be a ValueObject passing immutable > > data > > from the input > > to be processed or passing immutable data to the output to be rendered. > > > > The great thing about Struts is that it gives you more than enough > > "rope" to > > use wisely or hang yourself :) > > > > robert > > > > > > > >> -----Original Message----- > >> From: Engbers, ir. J.B.O.M. [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, December 17, 2003 9:24 AM > >> To: '[EMAIL PROTECTED]' > >> Subject: Newbie: java.lang.boolean and DynaActionForm? > >> > >> > >> Hi, > >> > >> Both 'Struts in Action' and 'Programming Jakarta Struts' state that > >> ActionForms and DynaActionForms are nearly equivalent and the > >> main advantage > >> of using DynaActionForms is that you don't have to declare all the > >> getters > >> and setters. > >> In DynaAction Forms each property can be of a (array of a) > >> primitive types. > >> > >> Thanks to Pedro Salgado and Martin Gainty (see "Retrieving boolean > >> properties from a DynaActionForm" on december 16), I partially > >> succeeded in > >> solving the first problem which only confronted me with the next > >> problem :-( > >> And while looking for a solution to that problem, I found a bugreport > >> (23355) in which Craig states that > >> > >> 'Adding these (getInteger, getBoolean etc, Ben) would encourage a > >> behavior > >> that Struts discourages -- using > >> non-String data types in a form bean.' > >> > >> Maybe that this explains why I have only found examples that use > >> String-properties (which lead me to my first question: where can I > >> find > >> examples that use non_string properties?) but it leaves me with the > >> more > >> fundamental question: > >> Why do DynaActionForms offer the possibility to declare non-String > >> properties without supporting them? > >> Should I avoid using DynaActionForms at all and use the > >> DynaValidatorForm? > >> > >> Ben Engbers > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > --------------------------------------------------------------------- > 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]