On Fri, 11 Oct 2002, Rick Reumann wrote:
> Date: Fri, 11 Oct 2002 13:24:40 -0400
> From: Rick Reumann <[EMAIL PROTECTED]>
> To: Craig R. McClanahan <[EMAIL PROTECTED]>
> Cc: Struts Users Mailing List <[EMAIL PROTECTED]>
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
