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]
