[cgiapp] Anyone tried param validation with Brannigan.pm?

[Michael Peters]

On 07/26/2010 08:51 AM, Jason Purdy wrote:

> After giving Brannigan a cursory glance, it looks pretty nice, but what
> does this offer that Data::FormValidator doesn't?

 From the opposite point of view, here are some things that Brannigan 
doesn't do that DFV does do and that I can't live without:

1) Validations can't be stacked. In my applications I like to give error 
messages depending on what's wrong, not just a simple blanket "didn't 
pass" kind of thing. So if I have an email field that must be less than 
255 characters, all ascii chars, must be a valid email address, with a 
valid MX message and must not already exist in the database, then I want 
a separate error message for all of those. I can do this with DFV with 
custom constraint routines. This is an example that's almost exactly 
like what I have in an existing application:

   my $profile = {
       required           => ['email', 'name'],
       constraint_methods => {
           email => [
               string(max => 255, ascii_only => 1),
               email(check_mx => 1),
               unique(table => 'person', column => 'email'),
           ]
       },
   };

Then with the resulting Data::FormValidator::Results object I can check 
not only which fields, but which constraints. And those custom 
constraint methods can set flags (like the name of the constraint 
failure) which help me determine if, for instance the email() constraint 
failed because it wasn't an email address or if that MX record was bad.

2) Built-in validation methods get special treatment. In DFV the only 
difference between built-in methods and custom methods are the package 
you import them from. All of them are higher-order subs which return 
subs that interact with the Data::FormValidator::Results object.

It seems to me from looking at the Brannigan docs that built-ins get 
extra keys to make them easier to use but custom validation methods use 
the validate keyword. This means that it you can't distinguish between 
multiple types of failures in custom validation routines (see #1 above)

3) No filters. With DFV you can have filters like trim(), alphanum(), 
etc. These can be applied to all of your input fields or just certain 
ones. Brannigan looks like it can do single fields with the "parse" 
attribute, but I don't see any way to do that for every input.

4) Taint-handling. Almost all the time if I've validated some input it 
should also be considered non-tainted. And if it shouldn't I can turn 
that off selectively. But it's almost always what people want.

5) Better group handling: In DFV we have require_some, dependencies and 
dependency_groups. Not used in every form but really nice to have when 
you need them.

-- 
Michael Peters
Plus Three, LP