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 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################