Skip site navigation (1) Skip section navigation (2)

Re: Reducing duplicated business rules

From: Michael Glaesemann <grzm(at)myrealbox(dot)com>
To: pgsql-php(at)postgresql(dot)org
Subject: Re: Reducing duplicated business rules
Date: 2003-11-06 16:16:54
Message-ID: A2ECC7B4-1074-11D8-B410-0005029FC1A7@myrealbox.com (view raw or flat)
Thread:
Lists: pgsql-php
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

In response to

Responses

pgsql-php by date

Next:From: Michael GlaesemannDate: 2003-11-06 17:55:43
Subject: Re: Reducing duplicated business rules
Previous:From: Daniel StruckDate: 2003-11-06 15:52:10
Subject: Re: Reducing duplicated business rules

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group