The hard part of course is that half of the validation is trivial "must be a
date" or "integer in range" and the other half needs to be confirmed against
the database.
This is where HTML clients break down. It's difficult to have server
validation occur in the middle of the entry process, such as entering a
valid Customer Code or something.
(big hand wave here, I'm sure that it might be possible with some very savvy
Javascript hacking, I'm just not that savvy, and from what I have seen it's
fairly complicated to get working.)
I would have the trivial client side validation done on the client side, and
then also do it on the server side. The reason I would do that is because
then the server side can be used from a potentially unvalidating client
(say, a SOAP message or something), and the trivial validation is really not
that expensive compared to a Customer lookup.
So here's a question for anyone interested: if you were designing a
notation for expressing validation contraints in a manner independent of
language and platform, and suitable to use in both highly interactive
client-side validation and less interactive server-side validation, what
would it look like? Or do you have a different idea on how to solve
this code duplication problem?
I think for a wide variety of validations, they can be readily expressed in
a simple syntax. The difficulty is in fields that are nominally trivial, but
related to other fields. For example, HotelCheckOutDate must be a date and
greater than HotelCheckInDate. That can complicate it fairly readily, but
it's not really horrible as most field sets on forms (or set of forms) are
pretty self contained.
But once you abstract your validations into a simple, contrived syntax, you
basically store this as meta data and then have the clients load them
appropriately, and then have a validation engine the interprets the simple
syntax and performs the validation. Or, say for an HTML client, it compiles
the data into a javascript validation function that is downloaded with the
page. The same meta data can be used on both ends, and this cleans up the
code duplication as its centrally located rather than compiled into the
application.
Also, if you can make the validation selective depending on the client. So,
you can express all of your validation, and only the parts that are actually
available to the client are sent to it.
For example:
(field customerNo (type char 10) (exists select customerNo from
customerTable where customerNo = :customerNo))
(field arrivalDate (type date) (> arrivalDate currentDate))
(field leaveDate (type date) (> leaveDate arrivalDate))
(field noGuests (type number) (between 1 6))
(field smoking (type char 10) (list "Smoking" "Non-Smoking" "No
Preference"))
(field roomType (type char 10) (list "King" "Double" "Suite"))
(page (required customerNo arrivalDate leaveDate noGuest roomType))
That information can easily be filtered to not send the CustomerNo
validation to the client, as, say, the server only has access to the
database. The rest can be handled easily by the client. The page clause
represents validation that happens on submit. Interpreting and/or compiling
something like this is really trivial to do.
But store it in a neutral format that's easy for applications to leverage,
and you eliminate the duplication issue, though not necessarily a versioning
problem. Say the roomType field was new and an old client tried to contact
the server. It might return an error message "Please fill in room type", yet
there isn't one on the screen.
So, you can make it as complicated as you like.
Regards,
Will Hartung
(
[email protected])
