Item Description: Helps the process of validating HTML forms
Review Synopsis:
I spend a lot of time writing perl to process HTML forms. I soon realized that I was writing very similar code in each case. Some common tasks of form validation include:
- making sure required fields are populated
- trimming leading and trailing whitespace off of input.
- handling fields that become required when another field is filled in
- validating common input types -- answering such questions as "is this a valid email?", "is this valid zipcode?", "is this valid telephone number?".
{ customer_infos => { optional => [ qw( company fax country ) ], required => [ qw( fullname phone email address city state zipcode ) ], constraints => { email => "email", fax => "american_phone", phone => "american_phone", zipcode => '/^\s*\d{5}(?:[-]\d{4})?\s*$/', state => "state", }, defaults => { country => "USA", }, }, customer_billing_infos => { optional => [ "cc_no" ], dependencies => { "cc_no" => [ qw( cc_type cc_exp ) ], }, constraints => { cc_no => { constraint => "cc_number", params => [ qw( cc_no cc_type ) ], }, cc_type => "cc_type", cc_exp => "cc_exp", } filters => [ "trim" ], field_filters => { cc_no => "digit" }, }, }Any validation that you want to yourself you can add in, so you aren't limited to just the options that this module provides. Additionally, HTML::FormValidator doesn't force you to handle the form validations errors in any particular way. Instead it returns the results like this:
my( $valids, $missings, $invalids, $unknowns ) = $validator->validate( \%fdat, "customer_infos" );Here $valids will be a hash ref, and the other values will be array refs. A nice side effect of this arrangement is that if you've named your form fields with the same names as some database columns, you can now pass your $valids hash ref directly to a module like DBIx::Abstract to insert the results into a database, auto-quoting the values along the way.