Re: Reducing duplicated business rules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [Postgresql General]     [Postgresql Admin]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Backpacking]     [Postgresql Jobs]

  Powered by Linux