Re: Better handling of constraint failures?

[prev] [thread] [next] [Date index for 2004/08/12]

dan@xxxxxxxxxxxx.xxx wrote:
 >
> The reason I want to catch constraint failures is because I want the
> constraint checking to act as my HTML form validation check: If the
> constraint check barfs, I want to re-output the form with an error
> message on the field that failed. Without an easy way to know which
> field failed, this won't be easy. Using CDBI constraints to check
> form values seems like a pretty good way to not repeat myself. . .
> but I need to give the user specific feedback about the failure.

Hmmm, here's some food for thought. I'm currently using 
Data::FormValidator for my param checking. It works great and I've got 
it integrated into my application base class so I get it pretty much for 
free.

But I also have constraints for some columns in a few CDBI classes. So 
now I have constraints in 2 places: my D::FV profiles and my CDBI class. 
It would be nice if there were a way to "export" the constraints with my 
CDBI classes so that I can easily integrate that with D::FV. Something like:

my $cdbi_cons = Class->export_constraints;
my $dfv_profiles = {runmode1=>{required=>['foo'],
                                constraints=>$cdbi_cons,
                               }};
# do actual D::FV validation here

The idea here is that it's MUCH easier for me to have the D::FV failures 
integrated with my forms than CDBI constraints. I already have glue code 
setup so that all failures are caught and properly displayed to the 
user. Thoughts? Did I explain myself properly?

Drew
        -- 
        ----------------------------------------------------------------
Drew Taylor                 *  Web development & consulting
Email: drew@xxxxxxxxxx.xxx  *  Site implementation & hosting
Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------