NAME

HTML::FormValidator - Validates user input (usually from an HTML form) based on input profile.

SYNOPSIS

In an HTML::Empberl page:

use HTML::FormValidator;

my $validator = new HTML::FormValidator( "/home/user/input_profiles.pl" );
my ( $valid, $missing, $invalid, $unknown ) = $validator->validate(  \%fdat, "customer_infos" );

DESCRIPTION

HTML::FormValidator's main aim is to make the tedious coding of input validation expressible in a simple format and to let the programmer focus on more interesting task.

When you are coding web application one of the most tedious though crucial task is to validate user's input (usually submitted by way of an HTML form). You have to check that each required fields is present and that some feed have valid data. (Does the phone input looks like a phone number ? Is that a plausible email address ? Is the YY state valid ? etc.) For simple form, this is not really a problem but as forms get more complex and you code more of them this task became really boring and tedious.

HTML::FormValidator lets you defines profiles which defines the required fields and their format. When you are ready to validate the user's input, you tell HTML::FormValidator the profile to apply to the user data and you get the valid fields, the name of the fields which are missing, the name of the fields that contains invalid input and the name of the fields that are unknown to this profile.

You are then free to use this information to build a nice display to the user telling which fields that he forgot to fill.

INPUT PROFILE SPECIFICATION

To create a HTML::FormValidator, use the following :

my $validator = new HTML::FormValidator( $input_profile );

Where $input_profile may either be an hash reference to an input profiles specification or a file that will be evaluated at runtime to get a hash reference to an input profiles specification.

The input profiles specification is an hash reference where each key is the name of the input profile and each value is another hash reference which contains the actual profile elements. If the input profile is specified as a file name, the profiles will be reread each time that the disk copy is modified.

Here is an example of a valid input profiles specification :

    {
	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" },
	},
    }

The following are the valid fields for an input specification :

required

This is an array reference which contains the name of the fields which are required. Any fields in this list which are not present in the user input will be reported as missing.

optional

This is an array reference which contains the name of optional fields. These are fields which MAY be present and if they are, they will be check for valid input. Any fields not in optional or required list will be reported as unknown.

dependencies

This is an hash reference which contains dependencies information. This is for the case where one optional fields has other requirements. For example, if you enter your credit card number, the field cc_exp and cc_type should also be present. Any fields in the dependencies list that is missing when the target is present will be reported as missing.

defaults

This is an hash reference which contains defaults which should be substituted if the user hasn't filled the fields. Key is field name and value is default value which will be returned in the list of valid fields.

filters

This is a reference to an array of filters that will be applied to ALL optional or required fields. This can be the name of a builting filter (trim,digit,etc) or an anonymous subroutine which should take one parameter, the field value and return the (possibly) modified value.

field_filters

This is a reference to an hash which contains reference to array of filters which will be apply to specific input fields. The key of the hash is the name of the input field and the valud is a reference to an array of filters like for the filters parameter.

constraints

This is a reference to an hash which contains the constraints that will be used to check wheter or not the field contains valid data. Constraint can be either the name of a builtin constraint function (see below), a perl regexp or an anonymous subroutine which will check the input and return true or false depending on the input's validity.

The constraint function takes one parameter, the input to be validated and returns true or false. It is possible to specify the parameters that will be passed to the subroutine. For that use an hash reference which contains in the constraint element, the anonymous subroutine or the name of the builtin and in the params element the name of the fields to pass a parameter to the function. (Don't forget to include the name of the field to check in that list!) For an example, look at the cc_no constraint example.

VALIDATING INPUT

    my( $valids, $missings, $invalids, $unknowns ) =
	$validator->validate( \%fdat, "customer_infos" );

To validate input you use the validate() method. This method takes two parameters :

data

Contains an hash which should correspond to the form input as submitted by the user. This hash is not modified by the call to validate.

profile

Can be either a name which will be used to lookup the corresponding profile in the input profiles specification, or it can be an hash reference to the input profile which should be used.

This method returns a 4 elements array.

valids

This is an hash reference to the valid fields which were submitted in the data. The data may have been modified by the various filters specified.

missings

This is a reference to an array which contains the name of the missing fields. Those are the fields that the user forget to fill or filled with space. These fields may comes from the required list or the dependencies list.

invalids

This is a reference to an array which contains the name of the fields which failed their constraint check.

unknowns

This is a list of fields which are unknown to the profile. Whether or not this indicates an error in the user input is application dependant.

INPUT FILTERS

These are the builtin filters which may be specified as name in the filters and field_filters parameters of the input profile.

trim

Remove white space at the front and end of the fields.

strip

Runs of white space are replaced by a single space.

digit

Remove non digits characters from the input.

alphanum

Remove non alphanumerical characters from the input.

integer

Extract from its input a valid integer number.

pos_integer

Extract from its input a valid positive integer number.

pos_integer

Extract from its input a valid negative integer number.

decimal

Extract from its input a valid decimal number.

pos_decimal

Extract from its input a valid positive decimal number.

neg_decimal

Extract from its input a valid negative decimal number.

dollars

Extract from its input a valid number to express dollars like currency.

phone

Filters out characters which aren't valid for an phone number. (Only accept digits [0-9], space, comma, minus, parenthesis, period and pound [#].)

sql_wildcard

Transforms shell glob wildcard (*) to the SQL like wildcard (%).

quotemeta

Calls the quotemeta (quote non alphanumeric character) builtin on its input.

lc

Calls the lc (convert to lowercase) builtin on its input.

uc

Calls the uc (convert to uppercase) builtin on its input.

ucfirst

Calls the ucfirst (Uppercase first letter) builtin on its input.

BUILTIN VALIDATOR

Those are the builtin constraint that can be specified by name in the input profiles.

email

Checks if the email LOOKS LIKE an email address. This checks if the input contains one @, and a two level domain name. The address portion is checked quite liberally. For example, all those probably invalid address would pass the test :

nobody@top.domain
%?&/$()@nowhere.net
guessme@guess.m
state_or_province

This one checks if the input correspond to an american state or a canadian province.

state

This one checks if the input is a valid two letter abbreviation of an american state.

province

This checks if the input is a two letter canadian province abbreviation.

zip_or_postcode

This constraints checks if the input is an american zipcode or a canadian postal code.

postcode

This constraints checks if the input is a valid Canadian postal code.

zip

This input validator checks if the input is a valid american zipcode : 5 digits followed by an optional mailbox number.

phone

This one checks if the input looks like a phone number, (if it contains at least 6 digits.)

american_phone

This constraints checks if the number is a possible North American style of phone number : (XXX) XXX-XXXX. It has to contains more than 7 digits.

cc_number

This is takes two parameters, the credit card number and the credit cart type. You should take the hash reference option for using that constraint.

The number is checked only for plausibility, it checks if the number could be valid for a type of card by checking the checksum and looking at the number of digits and the number of digits of the number.

This functions is only good at weeding typos and such. IT DOESN'T CHECK IF THERE IS AN ACCOUNT ASSOCIATED WITH THE NUMBER.

cc_exp

This one checks if the input is in the format MM/YY or MM/YYYY and if the MM part is a valid month (1-12) and if that date is not in the past.

cc_type

This one checks if the input field starts by M(asterCard), V(isa), A(merican express) or D(iscovery).

CREDITS

Some of those input validation functions have been taken from MiniVend by Michael J. Heins <mike@heins.net>

The credit card checksum validation was taken from contribution by Bruce Albrecht <bruce.albrecht@seag.fingerhut.com> to the MiniVend program.

AUTHOR

Copyright (c) 1999 Francis J. Lacoste and iNsu Innovations Inc. All rights reserved.

Parts Copyright 1996-1999 by Michael J. Heins <mike@heins.net> Parts Copyright 1996-1999 by Bruce Albrecht <bruce.albrecht@seag.fingerhut.com>

This program is free software; you can redistribute it and/or modify it under the terms as perl itself.