view release on metacpan or  search on metacpan

lib/Data/FormValidator.pm  view on Meta::CPAN

 untaint_constraint_fields => [qw(zipcode state)],

Specifies that one or more fields will be untainted if they pass their
constraint(s). This can be set to a single field name or an array reference of
field names. The untainted data will be returned in the valid hash.

This overrides the untaint_all_constraints flag.

=head2 untaint_regexp_map

 untaint_regexp_map => [qr/some_field_\d/],

Specifies that certain fields will be untainted if they pass their constraints
and match one of the regular expressions supplied. This can be set to a single
regex, or an array reference of regexes. The untainted data will be returned
in the valid hash.

The above example would untaint the fields named C<some_field_1>, and C<some_field_2>
but not C<some_field>.

This overrides the untaint_all_constraints flag.

=head2 missing_optional_valid

 missing_optional_valid => 1

This can be set to a true value to cause optional fields with empty values to
be included in the valid hash. By default they are not included-- this is the
historical behavior.

This is an important flag if you are using the contents of an "update" form to
update a record in a database. Without using the option, fields that have been
set back to "blank" may fail to get updated.

=head2 validator_packages

 # load all the constraints and filters from these modules
 validator_packages => [qw(Data::FormValidator::Constraints::Upload)],

This key is used to define other packages which contain constraint routines or
filters.  Set this key to a single package name, or an arrayref of several. All
of its constraint and filter routines  beginning with 'match_', 'valid_' and
'filter_' will be imported into Data::FormValidator.  This lets you reference
them in a constraint with just their name, just like built-in routines.  You
can even override the provided validators.

See L<Writing your own constraint routines|Data::FormValidator::Constraints/"WRITING YOUR OWN CONSTRAINT ROUTINES">
documentation for more information

=head2 msgs

This key is used to define parameters related to formatting error messages
returned to the user.

By default, invalid fields have the message "Invalid" associated with them
while missing fields have the message "Missing" associated with them.

In the simplest case, nothing needs to be defined here, and the default values
will be used.

The default formatting applied is designed for display in an XHTML web page.
That formatting is as followings:

    <span style="color:red;font-weight:bold" class="dfv_errors">* %s</span>

The C<%s> will be replaced with the message. The effect is that the message
will appear in bold red with an asterisk before it. This style can be overridden by simply
defining "dfv_errors" appropriately in a style sheet, or by providing a new format string.

Here's a more complex example that shows how to provide your own default message strings, as well
as providing custom messages per field, and handling multiple constraints:

 msgs => {

     # set a custom error prefix, defaults to none
     prefix=> 'error_',

     # Set your own "Missing" message, defaults to "Missing"
     missing => 'Not Here!',

     # Default invalid message, default's to "Invalid"
     invalid => 'Problematic!',

     # message separator for multiple messages
     # Defaults to ' '
     invalid_separator => ' <br /> ',

     # formatting string, default given above.
     format => 'ERROR: %s',

     # Error messages, keyed by constraint name
     # Your constraints must be named to use this.
     constraints => {
                     'date_and_time' => 'Not a valid time format',
                     # ...
     },

     # This token will be included in the hash if there are
     # any errors returned. This can be useful with templating
     # systems like HTML::Template
     # The 'prefix' setting does not apply here.
     # defaults to undefined
     any_errors => 'some_errors',
 }

The hash that's prepared can be retrieved through the C<msgs> method
described in the L<Data::FormValidator::Results> documentation.

=head2 msgs - callback

I<This is a new feature. While it expected to be forward-compatible, it hasn't
yet received the testing the rest of the API has.>

If the built-in message generation doesn't suit you, it is also possible to
provide your own by specifying a code reference:

 msgs  =>  \&my_msgs_callback

This will be called as a L<Data::FormValidator::Results> method.  It may
receive as arguments an additional hash reference of control parameters,
corresponding to the key names usually used in the C<msgs> area of the