Re: Reducing duplicated business rules

Peter

Thanks for your reply. It's good to hear others thoughts on this.

On Thursday, November 6, 2003, at 10:46 AM, Peter Bayley wrote:

> My preference would be towards identifying bad data as soon as
> possible and
> thus provide the user a better (more interactive) experience. For me
> this
> means more clevers on the client -

> ie some JavaScript to check dates, formats, etc.

I've seen elsewhere people using JavaScript for checking these things.
I do the same thing within PHP, primarily because I don't know
JavaScript and have been able to get the job done (I think) in PHP
alone. I ask this from a position of ignorance, not of questioning your
judgement: What is the advantage of using JavaScript over PHP for
checking? This is completely a wild guess on my part, but does it have
to do with server load? I know to use PHP to check these things I end
up sending the form back to the server for processing. Looking again at
what you've written, I'm guessing this is exactly it. Using JavaScript
allows the client—rather than the server—do the checking. It seems to
me you'd pay an initial hit (downloading more into the client), but you
don't have to keep using the server to process/validate/check the data.
Am I close?

> Even better would be to call validation after each field has been
> changed so the user doesn't have to fill in the entire form before his
> or her errors are identified.

This is something I've been doing as well, or at least whenever a user
triggers some action (like a <select onchange="submit()">). I've
definitely noticed the delay in reloading the page, especially when I
have a long select list that's generated based on previously submitted
data (e.g., modifying select b's options depending on the choice in
select b).

> The other idea is to create some PostgreSQL-stored metadata with the
> form so
> that the rules for validation can be read from the database.

I've thought about this as well, but not enough to go about
implementing it. A lot of this thinking came from (as I mentioned in my
original post) finding I was writing a lot of validation code—actually
it seems *most* of my form code is validation :)—and reading about
Dataphor from material available from their site (www.alphora.com). It
appears that all of the information necessary for validation is housed
within the Dataphor DAE (Data Access Engine), and applications are able
to query the DAE to find out whether something would be accepted,
rather than just trying to insert or update the database and finding it
wouldn't work. Then whatever clients/apps accessed the DAE would have
access to the validation abilities, rather than including it in every
client/app. I'd like to give it a try, but I don't have a machine I can
run .NET on (even if I wanted to). Interesting stuff.

> This would allow PHP to read the validation rules for an input field
> (eg date must be
> in the future) and validate the field generically.

You know, this information has to be in the database already, right?
PostgreSQL itself has to store the integrity information somewhere (I'm
guessing the system catalogs). Just finding a way to make this more
accessible to the script. From what I've read (don't remember where),
one of the things that makes PostgreSQL special is it's extensive
system catalogs. Looking briefly, there's a system catalog called
pg_constraint which includes attributes such as consrc ("If a check
constraint, a human-readable representation of the expression"), and
contypid ("The domain this constraint is on; 0 if not a domain
constraint"). An immediate thought is that I don't see a way to do
domain checking. That of course doesn't mean there necessarily isn't
one—just thinking out loud here.

> It would also allow the PHP creating the input form in the first place
> to provide extra information in the form so that the pre-submit
> JavaScript function could also be
> generic - the same validation script would then read the validation
> rules -
> perhaps from hidden input fields and validate the corresponding input
> value.
> The metadata could include a PROMPT message that tells the user what is
> needed in a particular field.

It appears I should take a look at JavaScript (there's always another
language to learn!) and explore the system tables a little more. It
seems like there might be a way to make a layer between the PHP and
PostgreSQL that handles the constraint interpretation—in some generic
fashion that would allow it to talk to a variety of clients. (Maybe
there's already one out there somewhere.)

Thanks again for your comments. You've given me things to think about
and ideas about directions to go.

Michael
grzm myrealbox com