These constraints have a different naming convention because they are higher-order functions. They take input and return a code reference to a standard constraint method. A constraint name of length_between, min_length, or max_length will be set, corresponding to the function name you choose.

The checks are all inclusive, so a max length of '100' will allow the length 100.

Length is measured in perl characters as opposed to bytes or anything else.

This constraint will untaint your data if you have untainting turned on. However, a length check alone may not be enough to insure the safety of the data you are receiving. Using additional constraints to check the data is encouraged.

FV_num_values

Checks the number of values in the array named by this param. Note that this is useful for making sure that only one value was passed for a given param (by supplying a size argument of 1). A constraint name of num_values will be set.

cc_number

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 catching typos. 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).

ip_address

This checks if the input is formatted like a dotted decimal IP address (v4). For other kinds of IP address method, See Regexp::Common::net which provides several more options. "REGEXP::COMMON SUPPORT" explains how we easily integrate with Regexp::Common.

RENAMING BUILT-IN CONSTAINTS

If you'd like, you can rename any of the built-in constraints. Just define the constraint_method and name in a hashref, like this:

REGEXP::COMMON SUPPORT

Data::FormValidator also includes built-in support for using any of regular expressions in Regexp::Common as named constraints. Simply use the name of regular expression you want. This works whether you want to untaint the data or not. For example:

Notice that the routines are named with the prefix "FV_" instead of "RE_" now. This is simply a visual cue that these are slightly modified versions. We've made a wrapper for each Regexp::Common routine so that it can be used as a named constraint like this.

Be sure to check out the Regexp::Common syntax for how its syntax works. It will make more sense to add future regular expressions to Regexp::Common rather than to Data::FormValidator.

PROCEDURAL INTERFACE

You may also call these functions directly through the procedural interface by either importing them directly or importing the whole :validators group. This is useful if you want to use the built-in validators out of the usual profile specification interface.

For example, if you want to access the email validator directly, you could either do:

use Data::FormValidator::Constraints (qw/valid_email/);
or
use Data::FormValidator::Constraints (:validators);
if (valid_email($email)) {
# do something with the email address
}

Notice that when you call validators directly, you'll need to prefix the validator name with "valid_"

Each validator also has a version that returns the untainted value if the validation succeeded. You may call these functions directly through the procedural interface by either importing them directly or importing the :matchers group. For example if you want to untaint a value with the email validator directly you may:

WRITING YOUR OWN CONSTRAINT ROUTINES

New School Constraints Overview

The most flexible way to create constraints to use closures-- a normal seeming outer subroutine which returns a customized DFV method subroutine as a result. It's easy to do. These "constraint methods" can be named whatever you like, and imported normally into the name space where the profile is located.

Let's look at how this complex coolness constraint method works. The interface asks for users to define minimum and maximum coolness values, as well as declaring three data field names that we should peek into to look their values.

Old School Constraints

Here is documentation on how old school constraints are created. These are supported, but the new school style documented above is recommended.

See also the validator_packages option in the input profile, for loading sets of old school constraints from other packages.

Old school constraint routines are named two ways. Some are named with the prefix match_ while others start with valid_. The difference is that the match_ routines are built to untaint the data and return a safe version of it if it validates, while valid_ routines simply return a true value if the validation succeeds and false otherwise.

It is preferable to write match_ routines that untaint data for the extra security benefits. Plus, Data::FormValidator will AUTOLOAD a valid_ version if anyone tries to use it, so you only need to write one routine to cover both cases.

Usually constraint routines only need one input, the value being specified. However, sometimes more than one value is needed.

Using that syntax, the first parameter that will be passed to the routine is the Data::FormValidator object. The remaining parameters will come from the params array. Strings will be replaced by the values of fields with the same names, and references will be passed directly.

In addition to constraint_method, there is also an even older technique using the name constraint instead. Routines that are designed to work with constraintdon't have access to Data::FormValidator object, which means users need to pass in the name of the field being validated. Besides adding unnecessary syntax to the user interface, it won't work in conjunction with constraint_regexp_map.

Methods available for use inside of constraints

A few useful methods to use on the Data::FormValidator::Results object are available to you to use inside of your routine.

get_input_data()

Returns the raw input data. This may be a CGI object if that's what was used in the constraint routine.

By returning a closure which uses this method, you can build an advanced named constraint in your profile, before you actually have access to the DFV object that will be used later. See Data::FormValidator::Constraints::Upload for an example.

name_this is a provided as a shorter synonym.

The meta() method may also be useful to communicate meta data that may have been found. See Data::FormValidator::Results for documentation of that method.

BACKWARDS COMPATIBILITY

Prior to Data::FormValidator 4.00, constraints were specified a bit differently. This older style is still supported.

It was not necessary to explicitly load some constraints into your name space, and the names were given as strings, like this:

Related modules in this package

Data::FormValidator::ConstraintsFactory - This is a historical collection of constraints that suffer from cumbersome names. They are worth reviewing though-- make_and_constraint will allow to validate against a list of constraints and shortcircuit if the first one fails. That's perfect if the second constraint depends on the first one having passed. For a modern version of this toolkit, see Data::FormValidator::Constraints::MethodsFactory.