On 6/8/06, Dave Newton <[EMAIL PROTECTED]> wrote:
Frank W. Zammetti wrote:
> On Thu, June 8, 2006 1:09 pm, Michael Jouravlev wrote:
>
>> On the other hand, the whole idea of Struts/Commons Validator sucks
>> big time, because database already has all necessary validations,
>> domains, triggers, etc. Since most apps use database anyway, input
>> data should either be validated directly by a database or by DAO; DAO
>> should pull metadata from database to build validation/conversion
>> rules. Seems that Ruby on Rails is closer to this approach, while most
>> other frameworks do the same job twice or even three times.
>>
>
> I *totally* disagree with this :)
>
+1, and Frank didn't even mention that complex business-model-aware
validations most likely _can't_ be done in the database without a pretty
robust payer of triggers and stored procs, which are generally
DB-specific: I don't want to validate zipcodes for addresses anwhere but
at the outer-most levels of the app.
I want form validation to be done as close to the form as possible. I
want business-logic style validation to be done immediately following
generic form processing. DB-level validation (references, etc.) handled
last, and preferably the most generic.
IMHO, where and how to do what kinds of validations is going to be the next
"great debate" in application framework design :-) I'll sketch below what I
believe might be an ideal scenario, starting with a couple of motivating
goals:
* Enhance the user experience by catching errors as quickly
as possible (ideally client side in a webapp), with error messages that
are relevant to the user's context in that particular application.
* Minimize the number of times I need to specify the same
validation in source code, metadata, or whatever. Ideally, every
such requirement should be stated exactly once.
It's also important to recognize that there's more than one kind of
validation here ... the most important distinction being presentation ("is
the date entered by the user syntactically correct for the locale that the
user is interacting with" or "is this a correctly formatted credit card
number") versus business rules ("is the invoice date after the customer's
account-open date" or "is this credit card number and expiration date
actually valid"). Because the database will have date-oriented data already
converted to a DATE data type, it doesn't really seem appropriate to specify
the presentation style restrictions there (most likely it'd be the same
stuff for every single DATE in the entire schema). You've also got to deal
with interesting complexities such as fields that are required in some
contexts and not others, so you probably want some mechanism to deal with
exceptions or overrides of the embedded rules.
As to where/how to specify validation rules, using annotations for this (at
a couple of different levels) looks like an interesting possibility --
indeed, it was one of the topics that several of the Struts committers who
got together at JavaOne this year talked about briefly. One could envision
a situation where business logic validations were encoded as annotations on
the POJOs representing your persistence tier (JPA entity classes, Hibernate
based persistent classes, whatever), while presentation tier validations
were encoded on whatever things your presentation framework uses to store
the intermediate values (properties on an SAF1 ActionForm, or an SAF2/WW
action, or on JSF backing bean, for example). Ideally, your presentation
framework would also be able to "reach through" to the business rule
validations of the persistent objects your input forms are bound to, so it
could perform whatever business rule validations it was able to on the
client side (again, in a webapp world, perhaps by having your input field
widgets to AJAX callbacks to the server where necessary).
Indeed, this whole concept is relevant beyond just web frameworks ... it
would make sense in the long term to have a JSR that standardized a set of
validation annotations everyone could share, while giving various frameworks
the freedom to implement the semantics of doing the validation in whatever
fashion best fits the particular technologies that framework uses.
Dave
Craig
