On Thu, June 8, 2006 2:12 pm, Craig McClanahan wrote:
> IMHO, where and how to do what kinds of validations is going to be the
> next
> "great debate" in application framework design :-)
Hehe, it's a debate that's been around for a while, not sure it can be the
"next" great debate :) LOL
> * 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.
Absolutely agree.
> * 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.
Absolutely agree.
> 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").
This is of course true... interestingly, I recently did a sample app for
some folks at work to demonstrate using Commons Validator via AJAX calls.
In the demo, there was a textbox for an account number entry. The example
verifies that the account exists on a mainframe system, so I had a custom
rule that did the call to the mainframe and all that. This was done via
an AJAX call in response to the onBlur of the field. It's interesting
because I also demonstrated how the "regular" Struts app still worked with
exactly the same validation rules, and it also showed that you can indeed
code "business rules" in Commons Validator, and of course it showed how
you can essentially do an event-based validation from the client, all
using the same set of rules and code.
> 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.
Agreed.
> 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.
I'm still not sold on the whole concept of annotations myself... it seems
to encourage scattering things throughout the code base that otherwise
would be centralized. I do think it matters what is being annotated
though... I'm pretty strongly against annotating configuration information
for instance, but validation rules... that doesn't quute bother me as
much, not at first blush anyway.
A true validation JSR though, whatever the ultimate implementation
details, I could definitely get behind.
>
> Dave
>
>
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
