You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by rainer juenger <ja...@projektinter.net> on 2002/10/11 18:38:40 UTC
Struts forms best practice
Hi,
I was wondering what the best data type for Struts ActionForm class is.
According to the design I would say it should be the same as the data type
in the application.
(e.g. float) But then the associated form already comes with a "0" filed in
the form. That's something I don't wont at all!
As I found out, the only solution is to use String as data type an convert
it later.
Is there a more elegant way?
Rainer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts forms best practice
Posted by James Mitchell <jm...@telocity.com>.
No, Craig has mentioned this on several occasions. You are doing the right
thing by using String.
Craig wrote:
------------
Consider an integer property that (because of the limits of HTML) you
render as a text input field. Now assume your user types "1a3" instead of
"123" into the field. What is supposed to happen?
What the user expects, if they've ever used a GUI program of any sort, is
the following two things:
* An error message of some sort telling what is wrong
* The existing data that was typed will be reproduced
(even if it is wrong) so that only the bad part can
be fixed.
If you use a String property in your form bean for this field, both of
these expectations get met. If you use an int property in your form bean
for this field, you get a conversion error and an ugly exception.
Moral of the story -- form bean fields that correspond to text entry boxes
should always be strings, and you should do your conversion later (after
you've validated that it's possible). For checkboxes, you can use boolean
properties, because there are only two possible answers.
James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org
> -----Original Message-----
> From: rainer juenger [mailto:jakarta_rainer@projektinter.net]
> Sent: Friday, October 11, 2002 12:39 PM
> To: struts-user@jakarta.apache.org
> Subject: Struts forms best practice
>
>
> Hi,
>
> I was wondering what the best data type for Struts ActionForm class is.
> According to the design I would say it should be the same as the data type
> in the application.
> (e.g. float) But then the associated form already comes with a
> "0" filed in
> the form. That's something I don't wont at all!
> As I found out, the only solution is to use String as data type an convert
> it later.
>
> Is there a more elegant way?
>
> Rainer
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by Eddie Bush <ek...@swbell.net>.
Much of the commons is documented in this fashion. If you're skipping
reading the Javadocs for those components before trying to use them,
you're making your life unnecessarily more difficult ...
micael wrote:
> This was useful information to me. I never have used Javadocs much
> because I prefer to look at the source code. But, if there is
> overview information there, that would be very helpful. Just giving a
> little feedback from someone trying to get the way it works.
>
> I seem to learn better from seeing how the code works than from
> pieces. I am presently writing a tidbit for myself on what happens
> when Tomcat starts up, etc. I think I may shine it up and provide it
> if someone else might find that helpful. I need the overall picture
> and the smallest details, and the middle stuff doesn't do much for
> me. I only write that in case others have similar issues with
> documentation.
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by micael <ca...@harbornet.com>.
This was useful information to me. I never have used Javadocs much because
I prefer to look at the source code. But, if there is overview information
there, that would be very helpful. Just giving a little feedback from
someone trying to get the way it works.
I seem to learn better from seeing how the code works than from pieces. I
am presently writing a tidbit for myself on what happens when Tomcat starts
up, etc. I think I may shine it up and provide it if someone else might
find that helpful. I need the overall picture and the smallest details,
and the middle stuff doesn't do much for me. I only write that in case
others have similar issues with documentation.
The point was, however, to say thanks.
At 11:44 AM 10/11/2002 -0700, you wrote:
>On Fri, 11 Oct 2002, Vincent Stoessel wrote:
>
> > Date: Fri, 11 Oct 2002 13:51:22 -0400
> > From: Vincent Stoessel <vi...@xaymaca.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > Subject: Re: Struts forms best practice
> >
> >
> > >
> > > In the past, before using the copyProperties methods, I used a
> > > helper class to do the conversions which I liked, but using
> > > BeanUtils (and PropertyUtils) is much quicker.
> > >
> > > How do you suggest getting Dates in the proper format between
> > > form beans and model layer beans?
> > >
> > > Thanks,
> > >
> >
> > Hi, where can I learn more about using BeanUtils in struts. I haven't
> > (knowingly) played that toy yet.
>
>A good starting point would be the Javadocs. The "Package Description"
>section has a lot of useful background information and a bunch of
>examples.
>
> http://jakarta.apache.org/commons/beanutils/api/
>
>There's similar online documentation for the other Commons packages that
>Struts uses (and provides), such as Digester and Logging. In each case,
>the Javadocs includes user-level documentation on the summary pages.
>
> >
> > --
> > Vincent Stoessel
> > Linux Systems Developer
> > vincent xaymaca.com
>
>Craig
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Micael
-------------------------------------------------------
This electronic mail transmission and any accompanying documents contain
information belonging to the sender which may be confidential and legally
privileged. This information is intended only for the use of the
individual or entity to whom this electronic mail transmission was sent as
indicated above. If you are not the intended recipient, any disclosure,
copying, distribution, or action taken in reliance on the contents of the
information contained in this transmission is strictly prohibited. If you
have received this transmission in error, please delete the message. Thank you
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by Eddie Bush <ek...@swbell.net>.
Craig R. McClanahan wrote:
>On Fri, 11 Oct 2002, Eddie Bush wrote:
>
>>Date: Fri, 11 Oct 2002 12:58:17 -0500
>>From: Eddie Bush <ek...@swbell.net>
>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
>>To: Struts Users Mailing List <st...@jakarta.apache.org>
>>Subject: Re: Struts forms best practice
>>
>>That is a commons "toy" :-) The Struts code-base has examples of usage
>>in it though. The basics are quite easy:
>>
>>BeanUtils.copyProperties(dstBean, srcBean);
>>
>>If both the source and destination are of the same time
>>
>I assume you meant "of the same type".
>
Yes - that's what I meant. LOL - trying to do too many things
simultaneously right now, I think. (time is very much on my mind today)
>That's not strictly true. For example, either the source or destination
>bean can be a real JavaBean, or a DynaBean with the same property names.
>In addition, the source "bean" can actually be a Map.
>
>Oh, and did I tell you that you can also plug in your own String->Class
>and Class->String converters? :-) See ConvertUtils.register().
>
Yes :-)
My point (I think) was that PropertyUtils wouldn't determine
conversions. BeanUtils will (which is where you gain/lose speed). I
should have said something like "if their properties are of the same
type". By stating things the way I did, I suppose I (unintentionally)
gave the (incorrect) impression they would have to both be of the same
class - very bad :-/ Sorry.
>>(or, at least,
>>have the same signatures on their getters/setters) you may consider using:
>>
>>PropertyUtils.copyProperties(dstBean, srcBean);
>>
>>... since it doesn't try to do any conversions. BeanUtils will.
>>
>The PropertyUtils version will run much faster because of that.
>
... which is why I always try to point that out ;-) I did an
exceedingly poor job of explaining things this time around though -
thanks for catching me :-)
>>That's you "five-second 'all you need to know to get started using
>>BeanUtils' tutorial" ;-)
>>
>Craig
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, Eddie Bush wrote:
> Date: Fri, 11 Oct 2002 12:58:17 -0500
> From: Eddie Bush <ek...@swbell.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Struts forms best practice
>
> That is a commons "toy" :-) The Struts code-base has examples of usage
> in it though. The basics are quite easy:
>
> BeanUtils.copyProperties(dstBean, srcBean);
>
> If both the source and destination are of the same time
I assume you meant "of the same type".
That's not strictly true. For example, either the source or destination
bean can be a real JavaBean, or a DynaBean with the same property names.
In addition, the source "bean" can actually be a Map.
Oh, and did I tell you that you can also plug in your own String->Class
and Class->String converters? :-) See ConvertUtils.register().
> (or, at least,
> have the same signatures on their getters/setters) you may consider using:
>
> PropertyUtils.copyProperties(dstBean, srcBean);
>
> ... since it doesn't try to do any conversions. BeanUtils will.
The PropertyUtils version will run much faster because of that.
>
> That's you "five-second 'all you need to know to get started using
> BeanUtils' tutorial" ;-)
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by Eddie Bush <ek...@swbell.net>.
That is a commons "toy" :-) The Struts code-base has examples of usage
in it though. The basics are quite easy:
BeanUtils.copyProperties(dstBean, srcBean);
If both the source and destination are of the same time (or, at least,
have the same signatures on their getters/setters) you may consider using:
PropertyUtils.copyProperties(dstBean, srcBean);
... since it doesn't try to do any conversions. BeanUtils will.
That's you "five-second 'all you need to know to get started using
BeanUtils' tutorial" ;-)
Vincent Stoessel wrote:
>
>>
>> In the past, before using the copyProperties methods, I used a
>> helper class to do the conversions which I liked, but using
>> BeanUtils (and PropertyUtils) is much quicker.
>>
>> How do you suggest getting Dates in the proper format between
>> form beans and model layer beans?
>>
>> Thanks,
>>
>
>
> Hi, where can I learn more about using BeanUtils in struts. I haven't
> (knowingly) played that toy yet.
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, Vincent Stoessel wrote:
> Date: Fri, 11 Oct 2002 13:51:22 -0400
> From: Vincent Stoessel <vi...@xaymaca.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Struts forms best practice
>
>
> >
> > In the past, before using the copyProperties methods, I used a
> > helper class to do the conversions which I liked, but using
> > BeanUtils (and PropertyUtils) is much quicker.
> >
> > How do you suggest getting Dates in the proper format between
> > form beans and model layer beans?
> >
> > Thanks,
> >
>
> Hi, where can I learn more about using BeanUtils in struts. I haven't
> (knowingly) played that toy yet.
A good starting point would be the Javadocs. The "Package Description"
section has a lot of useful background information and a bunch of
examples.
http://jakarta.apache.org/commons/beanutils/api/
There's similar online documentation for the other Commons packages that
Struts uses (and provides), such as Digester and Logging. In each case,
the Javadocs includes user-level documentation on the summary pages.
>
> --
> Vincent Stoessel
> Linux Systems Developer
> vincent xaymaca.com
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by Vincent Stoessel <vi...@xaymaca.com>.
>
> In the past, before using the copyProperties methods, I used a
> helper class to do the conversions which I liked, but using
> BeanUtils (and PropertyUtils) is much quicker.
>
> How do you suggest getting Dates in the proper format between
> form beans and model layer beans?
>
> Thanks,
>
Hi, where can I learn more about using BeanUtils in struts. I haven't
(knowingly) played that toy yet.
--
Vincent Stoessel
Linux Systems Developer
vincent xaymaca.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: Struts forms best practice
Posted by Rick Reumann <ma...@reumann.net>.
On Friday, October 11, 2002, 2:58:44 PM, Craig wrote:
CRM> Without knowing what "crap out on me" means, it's impossible to diagnose
CRM> this. Are you getting an exception so you can look at a stack trace?
I didn't know BeanUtils.copyProperties() should be able to take a
String date and can convert it into a java.util.Date. For some
reason when I try using BeanUtils.copyProperties() and I have a
java.util.Date that needs to be populated from a String, I get a
java.lang.IllegalArgumentException: argument type mismatch
error. The String version of the date is in MMddyyyy format in
the form bean. I noticed when looking at ConvertUtils that it
doesn't seem to mention that java.util.Date is provided by
default (looks like only java.sql.Date is). Maybe that's the
cause of the argument type mismatch (since I'm using
java.util.Date)? Thanks for the heads up into looking at
ConvertUtils.register(). Maybe that will help if I read more on
how to register my own conversion.
Thanks for the help so far.
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[3]: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, Rick Reumann wrote:
> Date: Fri, 11 Oct 2002 14:17:19 -0400
> From: Rick Reumann <ma...@reumann.net>
> To: Craig R. McClanahan <cr...@apache.org>
> Cc: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re[3]: Struts forms best practice
>
>
>
> On Friday, October 11, 2002, 2:02:11 PM, Craig wrote:
>
>
> CRM> * Form bean property is a String.
> <SNIP>
> CRM> * Value/DTO objects would use the native data types
> CRM> (java.util.Date in this case). Property name would
> CRM> be the same "birthDate".
> <SNIP>
> CRM> * Either use a copyProperties method or write a custom
> CRM> helper method to copy all the individual properties.
> <SNIP>
>
> Thanks Craig. It seems like if you do like above (using the
> String birthDate in the form bean, and the native Date
> 'birthDate' in the model bean, then you don't get the benefit of
> using the BeanUtils.copyProperties() method?
Why not? BeanUtils.copyProperties() will automatically do the
String->Date conversion for you when copying from the form bean to the
value object. There's a default converter for this purpose built in, but
you can replace it with your own if you want (ConvertUtils.register()).
> I must be messing
> something up because BeanUtils.copyProperties() seems to crap
> out on me if I have native java.util.Date birthDate and form
> bean property birthDate.
Without knowing what "crap out on me" means, it's impossible to diagnose
this. Are you getting an exception so you can look at a stack trace?
> Even if I want to use a helper method
> to do the conversion, it seems like I have to throw out the
> BeanUtils.copyProperties() if I want to have a form bean String
> and java.util.Date with the same field name? What I'd like to
> be able to do is using the copyProperties() of BeanUtils to copy
> over all the Strings in the form bean to the String (or ints) in
> the value object and then use a helper to deal with the Strings
> that need to be converted to Dates. The problem I'm running into
> is it seems to be an 'either' 'or' deal. Either, I make sure
> their is a Date as a String also in my model bean or else I use
> helper class to convert everything and not use the
> BeanUtils/PropertyUtils. Is there a way around this? (besides
> doing what I've done and have two versions of the date object in
> the value object... one as a String and one as a java.util.Date)
> ?
>
> Thanks again
>
>
>
> --
>
> Rick
> mailto:maillist@reumann.net
>
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[3]: Struts forms best practice
Posted by Rick Reumann <ma...@reumann.net>.
On Friday, October 11, 2002, 2:02:11 PM, Craig wrote:
CRM> * Form bean property is a String.
<SNIP>
CRM> * Value/DTO objects would use the native data types
CRM> (java.util.Date in this case). Property name would
CRM> be the same "birthDate".
<SNIP>
CRM> * Either use a copyProperties method or write a custom
CRM> helper method to copy all the individual properties.
<SNIP>
Thanks Craig. It seems like if you do like above (using the
String birthDate in the form bean, and the native Date
'birthDate' in the model bean, then you don't get the benefit of
using the BeanUtils.copyProperties() method? I must be messing
something up because BeanUtils.copyProperties() seems to crap
out on me if I have native java.util.Date birthDate and form
bean property birthDate. Even if I want to use a helper method
to do the conversion, it seems like I have to throw out the
BeanUtils.copyProperties() if I want to have a form bean String
and java.util.Date with the same field name? What I'd like to
be able to do is using the copyProperties() of BeanUtils to copy
over all the Strings in the form bean to the String (or ints) in
the value object and then use a helper to deal with the Strings
that need to be converted to Dates. The problem I'm running into
is it seems to be an 'either' 'or' deal. Either, I make sure
their is a Date as a String also in my model bean or else I use
helper class to convert everything and not use the
BeanUtils/PropertyUtils. Is there a way around this? (besides
doing what I've done and have two versions of the date object in
the value object... one as a String and one as a java.util.Date)
?
Thanks again
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, Rick Reumann wrote:
> Date: Fri, 11 Oct 2002 13:24:40 -0400
> From: Rick Reumann <ma...@reumann.net>
> To: Craig R. McClanahan <cr...@apache.org>
> Cc: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re[2]: Struts forms best practice
>
>
>
> On Friday, October 11, 2002, 12:59:31 PM, Craig wrote:
>
> CRM> Form bean properties should generally be Strings, so that you can
> CRM> redisplay whatever the user actually typed. Do your conversions in the
> CRM> Action after validation is complete -- in 1.1b2 and later, you can use
> CRM> BeanUtils.copyProperties() to copy the form bean properties into a
> CRM> coresponding business object, complete with doing the conversions as
> CRM> needed.
>
> Craig, I'm doing exactly like above but I'm wondering how you
> deal with Dates that are entered. What I'm currently doing is
> having both a String representation of the date not only in the
> form bean but also in the Model layer bean (DTO/value object). So
> the form bean has "birthDateAsString" and the DTO has
> "birthDateAsString" and java.util.Date "birthDate". Whenever
> getBirthDate() is called it will call getBirthDateAsString() and
> do the proper conversion on the string to return the Date.
> (Similarly for when setBirthDate(Date d) is called it will also
> call setBirthDateAsString() with the appropriate String
> representation).
>
> The above seems to work fine but I'm wondering is there a better
> way to handle this? What I don't like about it is the model layer
> bean is tied to the presentation (format of Date). In order to get a
> different String representation of the Date (or even to enter a
> different String representation of the Date) you have to go in
> and change this model layer bean.
>
> In the past, before using the copyProperties methods, I used a
> helper class to do the conversions which I liked, but using
> BeanUtils (and PropertyUtils) is much quicker.
>
> How do you suggest getting Dates in the proper format between
> form beans and model layer beans?
>
My general strategy for dates (similar strategy on other types):
* Form bean property is a String. This is critically
important for re-displaying invalid input. Property
name would be "birthDate" (same as model tier) for ease
of use and communicating between page authors and
back-end developers.
* Value/DTO objects would use the native data types
(java.util.Date in this case). Property name would
be the same "birthDate".
* Either use a copyProperties method or write a custom
helper method to copy all the individual properties.
(I don't usually deal with apps that have enough users
where the performance difference here matters at all --
the ultimate database i/o is usually an order of
magnitude more important).
This is based on the assumption that your model tier wants to work with
native data types. I always use native types there -- the presentation
guys might build a fancy calendar control instead, and that should be
irrelevant to the model tier developers.
> Thanks,
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Struts forms best practice
Posted by Rick Reumann <ma...@reumann.net>.
On Friday, October 11, 2002, 12:59:31 PM, Craig wrote:
CRM> Form bean properties should generally be Strings, so that you can
CRM> redisplay whatever the user actually typed. Do your conversions in the
CRM> Action after validation is complete -- in 1.1b2 and later, you can use
CRM> BeanUtils.copyProperties() to copy the form bean properties into a
CRM> coresponding business object, complete with doing the conversions as
CRM> needed.
Craig, I'm doing exactly like above but I'm wondering how you
deal with Dates that are entered. What I'm currently doing is
having both a String representation of the date not only in the
form bean but also in the Model layer bean (DTO/value object). So
the form bean has "birthDateAsString" and the DTO has
"birthDateAsString" and java.util.Date "birthDate". Whenever
getBirthDate() is called it will call getBirthDateAsString() and
do the proper conversion on the string to return the Date.
(Similarly for when setBirthDate(Date d) is called it will also
call setBirthDateAsString() with the appropriate String
representation).
The above seems to work fine but I'm wondering is there a better
way to handle this? What I don't like about it is the model layer
bean is tied to the presentation (format of Date). In order to get a
different String representation of the Date (or even to enter a
different String representation of the Date) you have to go in
and change this model layer bean.
In the past, before using the copyProperties methods, I used a
helper class to do the conversions which I liked, but using
BeanUtils (and PropertyUtils) is much quicker.
How do you suggest getting Dates in the proper format between
form beans and model layer beans?
Thanks,
--
Rick
mailto:maillist@reumann.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Struts forms best practice
Posted by rainer juenger <ja...@projektinter.net>.
Hi Craig, Simon and James,
thanks!
Rainer
-----Ursprungliche Nachricht-----
Von: Craig R. McClanahan [mailto:craigmcc@apache.org]
Gesendet: Freitag, 11. Oktober 2002 19:00
An: Struts Users Mailing List
Betreff: Re: Struts forms best practice
On Fri, 11 Oct 2002, rainer juenger wrote:
> Date: Fri, 11 Oct 2002 18:38:40 +0200
> From: rainer juenger <ja...@projektinter.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts forms best practice
>
> Hi,
>
> I was wondering what the best data type for Struts ActionForm class is.
> According to the design I would say it should be the same as the data type
> in the application.
> (e.g. float) But then the associated form already comes with a "0" filed
in
> the form. That's something I don't wont at all!
> As I found out, the only solution is to use String as data type an convert
> it later.
>
> Is there a more elegant way?
>
Form bean properties should generally be Strings, so that you can
redisplay whatever the user actually typed. Do your conversions in the
Action after validation is complete -- in 1.1b2 and later, you can use
BeanUtils.copyProperties() to copy the form bean properties into a
coresponding business object, complete with doing the conversions as
needed.
> Raine
Craig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, Andy Kriger wrote:
> Date: Fri, 11 Oct 2002 13:06:30 -0400
> From: Andy Kriger <ak...@greaterthanone.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts forms best practice
>
> Does this mean that you will have an ActionForm with String fields and a
> ModelBean that basically has all the same fields but with the correct types?
> And that ModelBean is passed around the struts framework?
>
The model beans are passed around the back end, and sometimes exposed as
request attributes for read-only access from the presentation layer.
> If so, how do folks reduce code duplication between the utility ActionForm
> and the data modelling ModelBean?
Use DynaActionForm or DynaValidatorForm form beans so you don't actually
have to write form bean classes (except perhaps for custom reset() and/or
validate() methods). [Requires 1.1]
Make the developers providing your persistence tier logic provide you the
value objects (after all, they should be reusable in non-web-based apps as
well) so that you don't have to do all the work :-).
Use tools to generate form bean and/or value object classes from some
common description of the properties. I understand XDoclet can be used
for things like this; I'm sure there are others as well. If you adopt a
strategy of maintaining the data definitions and always generating the
classes you need, code "duplication" is a non-issue.
>
> -a
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts forms best practice
Posted by Andy Kriger <ak...@greaterthanone.com>.
Does this mean that you will have an ActionForm with String fields and a
ModelBean that basically has all the same fields but with the correct types?
And that ModelBean is passed around the struts framework?
If so, how do folks reduce code duplication between the utility ActionForm
and the data modelling ModelBean?
-a
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, October 11, 2002 13:00
To: Struts Users Mailing List
Subject: Re: Struts forms best practice
On Fri, 11 Oct 2002, rainer juenger wrote:
> Date: Fri, 11 Oct 2002 18:38:40 +0200
> From: rainer juenger <ja...@projektinter.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts forms best practice
>
> Hi,
>
> I was wondering what the best data type for Struts ActionForm class is.
> According to the design I would say it should be the same as the data type
> in the application.
> (e.g. float) But then the associated form already comes with a "0" filed
in
> the form. That's something I don't wont at all!
> As I found out, the only solution is to use String as data type an convert
> it later.
>
> Is there a more elegant way?
>
Form bean properties should generally be Strings, so that you can
redisplay whatever the user actually typed. Do your conversions in the
Action after validation is complete -- in 1.1b2 and later, you can use
BeanUtils.copyProperties() to copy the form bean properties into a
coresponding business object, complete with doing the conversions as
needed.
> Raine
Craig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts forms best practice
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 11 Oct 2002, rainer juenger wrote:
> Date: Fri, 11 Oct 2002 18:38:40 +0200
> From: rainer juenger <ja...@projektinter.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts forms best practice
>
> Hi,
>
> I was wondering what the best data type for Struts ActionForm class is.
> According to the design I would say it should be the same as the data type
> in the application.
> (e.g. float) But then the associated form already comes with a "0" filed in
> the form. That's something I don't wont at all!
> As I found out, the only solution is to use String as data type an convert
> it later.
>
> Is there a more elegant way?
>
Form bean properties should generally be Strings, so that you can
redisplay whatever the user actually typed. Do your conversions in the
Action after validation is complete -- in 1.1b2 and later, you can use
BeanUtils.copyProperties() to copy the form bean properties into a
coresponding business object, complete with doing the conversions as
needed.
> Raine
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>