On Wed, 13 Jun 2001, Jonathan Asbell wrote:
> Regarding your answer:
> "Of course, you need an 'it can't happen, but it did' sort of error catch
> for conversion errors when you copy the String versions of the properties to
> your actual business objects, "
>
> Are you assuming that I keep the form data as Strings until the business
> layer? This was my collegue's complaint about the ActionForms because they
> did not contain the "types" he was expecting, but rather just Strings. Where
> are you personally doing conversions?
>
There are two reasonable strategies for an ActionForm:
* Check the convertability of the input strings but don't save them.
* Convert the data to the appropriate native format, and provide a second
getter method (getOrderDateAsDate() or something) for the native format.
Note that, if you're using the latter strategy, your business object does
not need to worry about conversion errors -- because the setter for the
corresponding property (setOrderDate) will already be accepting a date.
There is a second set of issues around the *semantic* validity of an input
value ("is it really reasonable to set the order date to 153 years
ago?"). This is, again, something you can check in many cases in the form
bean's validate() method. But what do you do about a rule that "the order
date cannot be before this customer's credit was approved"? That kind of
rule should still be checked at the business logic layer, IMHO.
Craig McClanahan
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 13, 2001 11:01 PM
> Subject: Re: Type conversions - issues on where to do them
>
>
> >
> > This is an interesting question. I'll give you my take on it -- others
> > will have different opinions.
> >
> > On Wed, 13 Jun 2001, Jonathan Asbell wrote:
> >
> > > Hello all. I wanted to know where you are doing type conversion. The
> > > reason I ask is because to some extent one may choose to do slightly
> > > deeper validations in the ActionForm for reasons of expectation. The
> > > question remains as to the exact level of "light" validation we should
> > > do in the ActionForm. From reading the list it seems the general
> > > consensus is to only do validation of a value's existance. However,
> > > where do you do type conversion then? In the ActionForm? In the
> > > Action? In the BusinessObject layer? The issues are:
> > >
> > > 1) If I do it in the ActionForm and there is a problem in the Action,
> > > then I have to reconvert back to a String on the way back.;
> > >
> >
> > That's why I advocate that properties in an ActionForm should be Strings
> > instead of dates/ints/whatever.
> >
> > However, this is an issue that the validate() method can check, to catch
> > things as early as possible. Whether you actually save the converted
> > value here or not is a compute-time-versus-memory-space tradeoff, and
> > either solution is possible.
> >
> > > 2) If I do it in the Action, same problem, but also the argument has
> > > been brought to my attention that the ActionForm bean (although
> > > temporary) does not truly represent the data it contains (like when a
> > > value represents a double, money, or a Date)
> > >
> >
> > If you're using an ActionForm bean that uses validation (the default
> > case), and if your validate method checks for any type conversion
> > problems, then the Action can assume that the conversion will not
> > fail. Of course, you need an "it can't happen, but it did" sort of error
> > catch for conversion errors when you copy the String versions of the
> > properties to your actual business objects, but 99% of the time they won't
> > actually get triggered.
> >
> > > 3) If I do it in the Business Layer than the message has gone deeper
> > > into the application than necessary which sacrifices performance and
> > > needless use of resources.
> > >
> >
> > Type conversion errors should have been caught by now. Business objects
> > should deal with the native property types -- part of the role of the
> > Action is to be an adapter between the String representation (used by the
> > form beans) and the native representation (used by the business logic).
> >
> > Craig McClanahan
> >
> >
>
>
