I've not used them, but I believe the consensus of the list is, once you
have mastered how to use them, why use anything else?

Mark

-----Original Message-----
From: Xavier Combelle [mailto:xcombelle@;kaptech.com]
Sent: Thursday, October 31, 2002 6:12 AM
To: Struts Users Mailing List
Subject: RE: MVC Design: property in ActionForm or Bean with property in
ActionForm ?


So in your point of view, a DynaActionForm should be enougth for
any kind of form ?

Xavier

> -----Message d'origine-----
> De : Andrew Hill [mailto:andrew.david.hill@;gridnode.com]
> Envoye : jeudi 31 octobre 2002 12:00
> A : Struts Users Mailing List
> Objet : RE: MVC Design: property in ActionForm or Bean with property in
> ActionForm ?
>
>
> Well one problem with actually modelling you ints as ints in the
> ActionForm
> is what happens if your user types in something like "forty two"
> instead of
> "42"?
>
> I forget whether this causes an exception in the
> processPopulate() method of
> the RequestProcessor or if it silently converts it to the value 0. If the
> former you have a problem catching it and if the later (which I think is
> what happens?) how do you know whether that zero is supposed to be zero or
> if its because your hairbrained user entered garbage?
>
> Furthermore when you redisplay the page for them to try again its
> considered
> good practice to rub their noses in the mess they left (ie:
> redisplay "forty
> two" in the field) together with an appropriate error message next to that
> field...
> (Personally I think the wording of these sort of error messages should be
> written by the host of "the weakest link" tv show ... but alas ... best
> practice says they should be 'friendly' ;->)
>
>
> -----Original Message-----
> From: Xavier Combelle [mailto:xcombelle@;kaptech.com]
> Sent: Thursday, October 31, 2002 18:52
> To: Struts Users Mailing List; [EMAIL PROTECTED]
> Subject: RE: MVC Design: property in ActionForm or Bean with property in
> ActionForm ?
>
>
> I have nearly the same think
> but I use to create properties as Integer which avoid me
> to make a call to Integer.valueOf()
>
> Am I wrong ?
>
>
> Sincerly
> Xavier
> > -----Message d'origine-----
> > De : Andrew Hill [mailto:andrew.david.hill@;gridnode.com]
> > Envoye : jeudi 31 octobre 2002 11:42
> > A : Struts Users Mailing List
> > Objet : RE: MVC Design: property in ActionForm or Bean with property in
> > ActionForm ?
> >
> >
> > Technically speaking, the ActionForm IS a bean.
> > It's purpose is to represent the users input (which you can
> > validate and if
> > necessary redisplay for correction) before transferring in your
> action the
> > (validated) values (with appropriate type conversion) to your business
> > object and vice versa.
> > Your BO itself may well be a bean too - such as your "BookBean" perhaps?
> > The actionForm and the business object will of course have a
> very similar
> > (often identical) set of properties, however they serve different
> > purposes -
> > for example you will note that while your BOs beans would have various
> > property types (ie: int for pages etc...) you ActionForm will
> > *usually* just
> > be strings (some folk use bools for checkboxes though) - a result of it
> > being a place to store the string data submitted in the request
> > or read from
> > the BO ready for display in the form...
> >
> > -----Original Message-----
> > From: Marcus Biel [mailto:Marcus.Biel@;bmw.de]
> > Sent: Thursday, October 31, 2002 18:20
> > To: [EMAIL PROTECTED]
> > Subject: MVC Design: property in ActionForm or Bean with property in
> > ActionForm ?
> >
> >
> > What's better:
> >
> > To have a bean let's say "BookBean.java"
> > that has got a String title, author, pages
> >
> > and an Actionform that uses this BookBean,
> >
> > or is it better to have an ActionForm
> > that has a String title, author, pages.
> >
> > Imho it's much faster and easier to have your properties in your
> > ActionForm,
> >
> > but I bet according to the MVC design its recommend to use Beans.
> >
> >
> > Right ?
> >
> >
> > thx,
> >
> > marcus
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@;jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@;jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@;jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@;jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@;jakarta.apache.org>


--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>

Reply via email to