Well, just one hitch when doing the business validation in the Action. If
you are developing in an enterprise environment, you probably want to do
these kind of validations in a business object because, as pointed out in an
eariler thread, you may need data from the database to do this
validation/evaluation. Better that the validation for this level all be in
one place. In an enterprise app the Action would probably be considered
part of the web tier. Therfore, it would not be good to mix the two tiers.
What do you Think?
By the way Ted, thank you for being so open and taking the time to offer
your perspective. I really appreciate it and I'm sure everyone on the list
does as well. It makes this list truly worth while. Ditto to Oleg, Martin,
Michael, Johan, Peter, Nanduri, Jon, Jeff, Hal, David, and Craig. I have
learned alot in these 3 months.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 10:42 PM
Subject: Re: Type conversions - issues on where to do them
> The best practice is to perform domain validations in the ActionForm,
> like those possible with David W's validator. This means confirming that
> the String could be represented as the desired type. The original String
> captured by the ActionForm should never be altered (immutable except by
> the user).
>
> The type conversions can be handled by a helper object, which can be
> embedded in the ActionForm or elsewhere. If the conversions are handled
> by the ActionForm, the result should always be transfered to another
> property, leaving the original String intact. A good way to retrieve the
> data in this case is to have a separate accessor. So an ActionForm may
> have a getAccount() accessor and a getAccountInt() accessor, with the
> int property being set as part of the ActionForm validation. If the
> ActionForm makes it to the Action, the API contract would be that
> getAccountInt() will return a valid representation of getAccount as an
> int.
>
> Of course, the int returned may not be in a valid range, pursuant to
> some business logic. This level of validation should be perfomed in the
> Action, which can easily return the ActionForm to input if there is a
> problem. Another form of range might be a valid username and password.
>
> [ user input ] -> [ action form ] -> [ validate domain ] -> [ action ]
> -> [ validate range ] -> [ transfer to persistent storage or business
> logic beans ]
>
> Depending on the resources available, you may also prefer to do the type
> conversions within the Action. If the ActionForm validator is doing it's
> job, the conversions should not fail. Personally, I let the RowSets do
> most of my type conversions for me, which happens within the Action.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> > 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.;
> >
> > 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)
> >
> > 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.
>
