Provided by: libhtml-formhandler-perl_0.40068-1_all bug


       HTML::FormHandler - HTML forms using Moose


       version 0.40068


       See the manual at HTML::FormHandler::Manual.

           use HTML::FormHandler; # or a custom form: use MyApp::Form::User;
           my $form = HTML::FormHandler->new( .... );
           $form->process( params => $params );
           my $rendered_form = $form->render;
           if( $form->validated ) {
               # perform validated form actions
           else {
               # perform non-validated actions

       Or, if you want to use a form 'result' (which contains only the form values and error
       messages) instead:

           use MyApp::Form; # or a generic form: use HTML::FormHandler;
           my $form = MyApp::Form->new( .... );
           my $result = $form->run( params => $params );
           if( $result->validated ) {
               # perform validated form actions
           else {
               # perform non-validated actions

       An example of a custom form class:

           package MyApp::Form::User;

           use HTML::FormHandler::Moose;
           extends 'HTML::FormHandler';
           use Moose::Util::TypeConstraints;

           has '+item_class' => ( default => 'User' );

           has_field 'name' => ( type => 'Text' );
           has_field 'age' => ( type => 'PosInteger', apply => [ 'MinimumAge' ] );
           has_field 'birthdate' => ( type => 'DateTime' );
           has_field 'birthdate.month' => ( type => 'Month' );
           has_field '' => ( type => 'MonthDay' );
           has_field 'birthdate.year' => ( type => 'Year' );
           has_field 'hobbies' => ( type => 'Multiple' );
           has_field 'address' => ( type => 'Text' );
           has_field 'city' => ( type => 'Text' );
           has_field 'state' => ( type => 'Select' );
           has_field 'email' => ( type => 'Email' );

           has '+dependency' => ( default => sub {
                 [ ['address', 'city', 'state'], ]

           subtype 'MinimumAge'
              => as 'Int'
              => where { $_ > 13 }
              => message { "You are not old enough to register" };

           no HTML::FormHandler::Moose;

       A dynamic form - one that does not use a custom form class - may be created using the
       'field_list' attribute to set fields:

           my $form = HTML::FormHandler->new(
               name => 'user_form',
               item => $user,
               field_list => [
                   'username' => {
                       type  => 'Text',
                       apply => [ { check => qr/^[0-9a-z]*\z/,
                          message => 'Contains invalid characters' } ],
                   'select_bar' => {
                       type     => 'Select',
                       options  => \@select_options,
                       multiple => 1,
                       size     => 4,

       FormHandler does not provide a custom controller for Catalyst because it isn't necessary.
       Interfacing to FormHandler is only a couple of lines of code. See
       HTML::FormHandler::Manual::Catalyst for more details, or


       *** Although documentation in this file provides some overview, it is mainly intended for
       API documentation. See HTML::FormHandler::Manual::Intro for an introduction, with links to
       other documentation.

       HTML::FormHandler maintains a clean separation between form construction and form
       rendering. It allows you to define your forms and fields in a number of flexible ways.
       Although it provides renderers for HTML, you can define custom renderers for any kind of

       HTML::FormHandler allows you to define form fields and validators. It can be used for both
       database and non-database forms, and will automatically update or create rows in a
       database. It can be used to process structured data that doesn't come from an HTML form.

       One of its goals is to keep the controller/application program interface as simple as
       possible, and to minimize the duplication of code. In most cases, interfacing your
       controller to your form is only a few lines of code.

       With FormHandler you shouldn't have to spend hours trying to figure out how to make a
       simple HTML change that would take one minute by hand. Because you _can_ do it by hand. Or
       you can automate HTML generation as much as you want, with template widgets or pure Perl
       rendering classes, and stay completely in control of what, where, and how much is done
       automatically. You can define custom renderers and display your rendered forms however you

       You can split the pieces of your forms up into logical parts and compose complete forms
       from FormHandler classes, roles, fields, collections of validations, transformations and
       Moose type constraints.  You can write custom methods to process forms, add any attribute
       you like, and use Moose method modifiers.  FormHandler forms are Perl classes, so there's
       a lot of flexibility in what you can do.

       HTML::FormHandler provides rendering through roles which are applied to form and field
       classes (although there's no reason you couldn't write a renderer as an external object
       either).  There are currently two flavors: all-in-one solutions like
       HTML::FormHandler::Render::Simple and HTML::FormHandler::Render::Table that contain
       methods for rendering field widget classes, and the HTML::FormHandler::Widget roles, which
       are more atomic roles which are automatically applied to fields and form. See
       HTML::FormHandler::Manual::Rendering for more details.  (And you can easily use hand-built
       forms - FormHandler doesn't care.)

       The typical application for FormHandler would be in a Catalyst, DBIx::Class, Template
       Toolkit web application, but use is not limited to that. FormHandler can be used in any
       Perl application.

       More Formhandler documentation and a tutorial can be found in the manual at


   Creating a form with 'new'
       The new constructor takes name/value pairs:

               item    => $item,

       No attributes are required on new. The form's fields will be built from the form
       definitions. If no initial data object or defaults have been provided, the form will be
       empty. Most attributes can be set on either 'new' or 'process'.  The common attributes to
       be passed in to the constructor for a database form are either item_id and schema or item:

          item_id  - database row primary key
          item     - database row object
          schema   - (for DBIC) the DBIx::Class schema

       The following are sometimes passed in, but are also often set in the form class:

          item_class  - source name of row
          dependency  - (see dependency)
          field_list  - an array of field definitions
          init_object - a hashref or object to provide initial values

       Examples of creating a form object with new:

           my $form = MyApp::Form::User->new;

           # database form using a row object
           my $form = MyApp::Form::Member->new( item => $row );

           # a dynamic form (no form class has been defined)
           my $form = HTML::FormHandler::Model::DBIC->new(
               item_id         => $id,
               item_class    => 'User',
               schema          => $schema,
               field_list         => [
                       name    => 'Text',
                       active  => 'Boolean',
                       submit_btn => 'Submit',

       See the model class for more information about 'item', 'item_id', 'item_class', and
       'schema' (for the DBIC model).  HTML::FormHandler::Model::DBIC.

       FormHandler forms are handled in two steps: 1) create with 'new', 2) handle with
       'process'. FormHandler doesn't care whether most parameters are set on new or process or
       update, but a 'field_list' argument must be passed in on 'new' since the fields are built
       at construction time.

       If you want to update field attributes on the 'process' call, you can use an
       'update_field_list' or 'defaults' hashref attribute , or subclass update_fields in your
       form. The 'update_field_list' hashref can be used to set any field attribute. The
       'defaults' hashref will update only the 'default' attribute in the field. (There are a lot
       of ways to set defaults. See HTML::FormHandler::Manual::Defaults.)

          $form->process( defaults => { foo => 'foo_def', bar => 'bar_def' } );
          $form->process( update_field_list => { foo => { label => 'New Label' } });

       Field results are built on the 'new' call, but will then be re-built on the process call.
       If you always use 'process' before rendering the form, accessing fields, etc, you can set
       the 'no_preload' flag to skip this step.

   Processing the form

       Call the 'process' method on your form to perform validation and update. A database form
       must have either an item (row object) or a schema, item_id (row primary key), and
       item_class (usually set in the form).  A non-database form requires only parameters.

          $form->process( item => $book, params => $c->req->parameters );
          $form->process( item_id => $item_id,
              schema => $schema, params => $c->req->parameters );
          $form->process( params => $c->req->parameters );

       This process method returns the 'validated' flag ("$form->validated").  If it is a
       database form and the form validates, the database row will be updated.

       After the form has been processed, you can get a parameter hashref suitable for using to
       fill in the form from "$form->fif".  A hash of inflated values (that would be used to
       update the database for a database form) can be retrieved with "$form->value".

       If you don't want to update the database on this process call, you can set the 'no_update'

          $form->process( item => $book, params => $params, no_update => 1 );


       Parameters are passed in when you call 'process'.  HFH gets data to validate and store in
       the database from the params hash.  If the params hash is empty, no validation is done, so
       it is not necessary to check for POST before calling "$form->process". (Although see the
       'posted' option for complications.)

       Params can either be in the form of CGI/HTTP style params:

             user_name => "Joe Smith",
             occupation => "Programmer",
             'addresses.0.street' => "999 Main Street",
             '' => "Podunk",
             '' => "UT",
             'addresses.0.address_id' => "1",
             'addresses.1.street' => "333 Valencia Street",
             '' => "San Francisco",
             '' => "UT",
             'addresses.1.address_id' => "2",

       or as structured data in the form of hashes and lists:

             addresses => [
                   city => 'Middle City',
                   country => 'GK',
                   address_id => 1,
                   street => '101 Main St',
                   city => 'DownTown',
                   country => 'UT',
                   address_id => 2,
                   street => '99 Elm St',
             'occupation' => 'management',
             'user_name' => 'jdoe',

       CGI style parameters will be converted to hashes and lists for HFH to operate on.


       Note that FormHandler by default uses empty params as a signal that the form has not
       actually been posted, and so will not attempt to validate a form with empty params. Most
       of the time this works OK, but if you have a small form with only the controls that do not
       return a post parameter if unselected (checkboxes and select lists), then the form will
       not be validated if everything is unselected. For this case you can either add a hidden
       field as an 'indicator', or use the 'posted' flag:

          $form->process( posted => ($c->req->method eq 'POST'), params => ... );

       The 'posted' flag also works to prevent validation from being performed if there are extra
       params in the params hash and it is not a 'POST' request.

   Getting data out
       fif  (fill in form)

       If you don't use FormHandler rendering and want to fill your form values in using some
       other method (such as with HTML::FillInForm or using a template) this returns a hash of
       values that are equivalent to params which you may use to fill in your form.

       The fif value for a 'title' field in a TT form:

          [% form.fif.title %]

       Or you can use the 'fif' method on individual fields:

          [% form.field('title').fif %]

       If you use FormHandler to render your forms or field you probably won't use these methods.


       Returns a hashref of all field values. Useful for non-database forms, or if you want to
       update the database yourself. The 'fif' method returns a hashref with the field names for
       the keys and the field's 'fif' for the values; 'value' returns a hashref with the field
       accessors for the keys, and the field's 'value' (possibly inflated) for the values.

       Forms containing arrays to be processed with HTML::FormHandler::Field::Repeatable will
       have parameters with dots and numbers, like '', while the values hash will
       transform the fields with numbers to arrays.

   Accessing and setting up fields
       Fields are declared with a number of attributes which are defined in
       HTML::FormHandler::Field. If you want additional attributes you can define your own field
       classes (or apply a role to a field class - see HTML::FormHandler::Manual::Cookbook). The
       field 'type' (used in field definitions) is the short class name of the field class, used
       when searching the 'field_name_space' for the field class.


       The most common way of declaring fields is the 'has_field' syntax.  Using the 'has_field'
       syntax sugar requires " use HTML::FormHandler::Moose; " or " use
       HTML::FormHandler::Moose::Role; " in a role.  See HTML::FormHandler::Manual::Intro

          use HTML::FormHandler::Moose;
          has_field 'field_name' => ( type => 'FieldClass', .... );


       A 'field_list' is an array of field definitions which can be used as an alternative to
       'has_field' in small, dynamic forms to create fields.

           field_list => [
              field_one => {
                 type => 'Text',
                 required => 1
              field_two => 'Text,

       The field_list array takes elements which are either a field_name key pointing to a 'type'
       string or a field_name key pointing to a hashref of field attributes. You can also provide
       an array of hashref elements with the name as an additional attribute.  The field list can
       be set inside a form class, when you want to add fields to the form depending on some
       other state, although you can also create all the fields and set some of them inactive.

          sub field_list {
             my $self = shift;
             my $fields = $self->schema->resultset('SomeTable')->
                                 search({user_id => $self->user_id, .... });
             my @field_list;
             while ( my $field = $fields->next )
                < create field list >
             return \@field_list;


       Used to dynamically set particular field attributes on the 'process' (or 'run') call.
       (Will not create fields.)

           $form->process( update_field_list => {
              foo_date => { format => '%m/%e/%Y', date_start => '10-01-01' } },
              params => $params );

       The 'update_field_list' is processed by the 'update_fields' form method, which can also be
       used in a form to do specific field updates:

           sub update_fields {
               my $self = shift;
               $self->field('foo')->temp( 'foo_temp' );
               $self->field('bar')->default( 'foo_value' );

       (Note that you although you can set a field's 'default', you can't set a field's 'value'
       directly here, since it will be overwritten by the validation process. Set the value in a
       field validation method.)


       Yet another way to provide settings for the field, except this one is intended for use in
       roles and compound fields, and is only executed when the form is initially built. It takes
       the same field name keys as 'update_field_list', plus 'all', 'by_flag', and 'by_type'.

           sub build_update_subfields {{
               all => { tags => { wrapper_tag => 'p' } },
               foo => { element_class => 'blue' },

       The 'all' hash key will apply updates to all fields. (Conflicting attributes in a field
       definition take precedence.)

       The 'by_flag' hash key will apply updates to fields with a particular flag.  The currently
       supported subkeys are 'compound', 'contains', and 'repeatable'.  (For repeatable
       instances, in addition to 'contains' you can also use the 'repeatable' key and the
       'init_contains' attribute.)  This is useful for turning on the rendering wrappers for
       compounds and repeatables, which are off by default. (The repeatable instances are wrapped
       by default.)

           sub build_update_subfields {{
               by_flag => { compound => { do_wrapper => 1 } },
               by_type => { Select => { element_class => ['sel_elem'] } },

       The 'by_type' hash key will provide values to all fields of a particular type.


       This is a more specialized version of the 'update_field_list'. It can be used to provide
       'default' settings for fields, in a shorthand way (you don't have to say 'default' for
       every field).

          $form->process( defaults => { foo => 'this_foo', bar => 'this_bar' }, ... );


       A field can be marked 'inactive' and set to active at new or process time by specifying
       the field name in the 'active' array:

          has_field 'foo' => ( type => 'Text', inactive => 1 );
          my $form = MyApp::Form->new( active => ['foo'] );
          $form->process( active => ['foo'] );

       Or a field can be a normal active field and set to inactive at new or process time:

          has_field 'bar';
          my $form = MyApp::Form->new( inactive => ['foo'] );
          $form->process( inactive => ['foo'] );

       Fields specified as active/inactive on new will have the form's inactive/active arrayref
       cleared and the field's inactive flag set appropriately, so that the state will be
       effective for the life of the form object. Fields specified as active/inactive on
       'process' will have the field's '_active' flag set for the life of the request (the
       _active flag will be cleared when the form is cleared).

       The 'sorted_fields' method returns only active fields, sorted according to the 'order'
       attribute. The 'fields' method returns all fields.

          foreach my $field ( $self->sorted_fields ) { ... }

       You can test whether a field is active by using the field 'is_active' and 'is_inactive'


       Use to look for field during form construction. If a field is not found with the
       field_name_space (or HTML::FormHandler/HTML::FormHandlerX), the 'type' must start with a
       '+' and be the complete package name.


       The array of fields, objects of HTML::FormHandler::Field or its subclasses.  A compound
       field will itself have an array of fields, so this is a tree structure.


       Returns those fields from the fields array which are currently active. This is the method
       that returns the fields that are looped through when rendering.

       field($name), subfield($name)

       'field' is the method that is usually called to access a field:

           my $title = $form->field('title')->value;
           [% f = form.field('title') %]

           my $city = $form->field('')->value;

       Pass a second true value to die on errors.

       Since fields are searched for using the form as a base, if you want to find a sub field in
       a compound field method, the 'subfield' method may be more useful, since you can search
       starting at the current field. The 'chained' method also works:

           -- in a compound field --
           $self->field('media.caption'); # fails
           $self->field('media')->field('caption'); # works
           $self->subfield('media.caption'); # works

   Constraints and validation
       Most validation is performed on a per-field basis, and there are a number of different
       places in which validation can be performed.

       See also HTML::FormHandler::Manual::Validation.

       Form class validation for individual fields

       You can define a method in your form class to perform validation on a field.  This method
       is the equivalent of the field class validate method except it is in the form class, so
       you might use this validation method if you don't want to create a field subclass.

       It has access to the form ($self) and the field.  This method is called after the field
       class 'validate' method, and is not called if the value for the field is empty ('',
       undef). (If you want an error message when the field is empty, use the 'required' flag and
       message or the form 'validate' method.)  The name of this method can be set with
       'set_validate' on the field. The default is 'validate_' plus the field name:

          sub validate_testfield { my ( $self, $field ) = @_; ... }

       If the field name has dots they should be replaced with underscores.

       Note that you can also provide a coderef which will be a method on the field:

          has_field 'foo' => ( validate_method => \&validate_foo );


       This is a form method that is useful for cross checking values after they have been saved
       as their final validated value, and for performing more complex dependency validation. It
       is called after all other field validation is done, and whether or not validation has
       succeeded, so it has access to the post-validation values of all the fields.

       This is the best place to do validation checks that depend on the values of more than one

   Accessing errors
       Also see HTML::FormHandler::Manual::Errors.

       Set an error in a field with "$field->add_error('some error string');".  Set a form error
       not tied to a specific field with "$self->add_form_error('another error string');".  The
       'add_error' and 'add_form_error' methods call localization. If you want to skip
       localization for a particular error, you can use 'push_errors' or 'push_form_errors'

         has_errors - returns true or false
         error_fields - returns list of fields with errors
         errors - returns array of error messages for the entire form
         num_errors - number of errors in form

       Each field has an array of error messages. (errors, has_errors, num_errors, clear_errors)


       Compound fields also have an array of error_fields.

   Clear form state
       The clear method is called at the beginning of 'process' if the form object is reused,
       such as when it is persistent in a Moose attribute, or in tests.  If you add other
       attributes to your form that are set on each request, you may need to clear those

       If you do not call the form's 'process' method on a persistent form, such as in a REST
       controller's non-POST method, or if you only call process when the form is posted, you
       will also need to call "$form->clear".

       The 'run' method which returns a result object always performs 'clear', to keep the form
       object clean.

   Miscellaneous attributes

       The form's name.  Useful for multiple forms. Used for the form element 'id'.  When
       'html_prefix' is set it is used to construct the field 'id' and 'name'.  The default is
       "form" + a one to three digit random number.  Because the HTML standards have flip-flopped
       on whether the HTML form element can contain a 'name' attribute, please set a name
       attribute using 'form_element_attr'.


       An 'init_object' may be used instead of the 'item' to pre-populate the values in the form.
       This can be useful when populating a form from default values stored in a similar but
       different object than the one the form is creating.  The 'init_object' should be either a
       hash or the same type of object that the model uses (a DBIx::Class row for the DBIC
       model). It can be set in a variety of ways:

          my $form = MyApp::Form->new( init_object => { .... } );
          $form->process( init_object => {...}, ... );
          has '+init_object' => ( default => sub { { .... } } );
          sub init_object { my $self = shift; .... }

       The method version is useful if the organization of data in your form does not map to an
       existing or database object in an automatic way, and you need to create a different type
       of object for initialization. (You might also want to do 'update_model' yourself.)

       Also see the 'use_init_obj_over_item' and the 'use_init_obj_when_no_accessor_in_item'
       flags, if you want to provide both an item and an init_object, and use the values from the

       The 'use_init_obj_when_no_accessor_in_item' flag is particularly useful when some of the
       fields in your form come from the database and some are process or environment type flags
       that are not in the database. You can provide defaults from both a database row and an


       Place to store application context for your use in your form's methods.


       See 'language_handle' and '_build_language_handle' in HTML::FormHandler::TraitFor::I18N.


       Arrayref of arrayrefs of fields. If one of a group of fields has a value, then all of the
       group are set to 'required'.

         has '+dependency' => ( default => sub { [
            ['street', 'city', 'state', 'zip' ],] }

       validated, is_valid

       Flag that indicates if form has been validated. You might want to use this flag if you're
       doing something in between process and returning, such as setting a stash key. ('is_valid'
       is a synonym for this flag)

          $form->process( ... );
          $c->stash->{...} = ...;
          return unless $form->validated;


       Flag to indicate that validation has been run. This flag will be false when the form is
       initially loaded and displayed, since validation is not run until FormHandler has params
       to validate.

       verbose, dump, peek

       Flag to dump diagnostic information. See 'dump_fields' and 'dump_validated'. 'Peek' can be
       useful in diagnosing bugs.  It will dump a brief listing of the fields and results.

          $form->process( ... );


       Flag to indicate that the form name is used as a prefix for fields in an HTML form. Useful
       for multiple forms on the same HTML page. The prefix is stripped off of the fields before
       creating the internal field name, and added back in when returning a parameter hash from
       the 'fif' method. For example, the field name in the HTML form could be "book.borrower",
       and the field name in the FormHandler form (and the database column) would be just

          has '+name' => ( default => 'book' );
          has '+html_prefix' => ( default => 1 );

       Also see the Field attribute "html_name", a convenience function which will return the
       form name + "." + field full_name


       Flag to indicate the fields will render using specialized attributes for html5.  Set to 0
       by default.


       The 'normal' precedence is that if there is an accessor in the item/init_object that value
       is used and not the 'default'. This flag makes the defaults of higher precedence. Mainly
       useful if providing an empty row on create.


       If you are providing both an item and an init_object, and want the init_object to be used
       for defaults instead of the item.

   For use in HTML
          form_element_attr - hashref for setting arbitrary HTML attributes
             set in form with: sub build_form_element_attr {...}
          form_element_class - arrayref for setting form tag class
          form_wrapper_attr - hashref for form wrapper element attributes
             set in form with: sub build_form_wrapper_attr {...}
          form_wrapper_class - arrayref for setting wrapper class
          do_form_wrapper - flag to wrap the form
          http_method - For storing 'post' or 'get'
          action - Store the form 'action' on submission. No default value.
          uuid - generates a string containing an HTML field with UUID
          form_tags - hashref of tags for use in rendering code
          widget_tags - rendering tags to be transferred to fields

       Discouraged (use form_element_attr instead):

          style - adds a 'style' attribute to the form tag
          enctype - Request enctype

       Note that the form tag contains an 'id' attribute which is set to the form name. The
       standards have been flip-flopping over whether a 'name' attribute is valid. It can be set
       with 'form_element_attr'.

       The rendering of the HTML attributes is done using the 'process_attrs' function and the
       'element_attributes' or 'wrapper_attributes' method, which adds other attributes in for
       backward compatibility, and calls the 'html_attributes' hook.

       For HTML attributes, there is a form method hook, 'html_attributes', which can be used to
       customize/modify/localize form & field HTML attributes.  Types: element, wrapper, label,
       form_element, form_wrapper, checkbox_label

          sub html_attributes {
              my ( $self, $obj, $type, $attrs, $result ) = @_;

              # obj is either form or field
              $attr->{class} = 'label' if $type eq 'label';
              $attr->{placeholder} = $self->_localize($attr->{placeholder})
                  if exists $attr->{placeholder};
              return $attr;

       Also see the documentation in HTML::FormHandler::Field and in



         Join #formhandler on

       Mailing list:

       Code repository:

       Bug tracker:















       gshank: Gerda Shank <>

       zby: Zbigniew Lukasiak <>

       t0m: Tomas Doran <>

       augensalat: Bernhard Graf <>

       cubuanic: Oleg Kostyuk <>

       rafl: Florian Ragwitz <>

       mazpe: Lester Ariel Mesa

       dew: Dan Thomas

       koki: Klaus Ita

       jnapiorkowski: John Napiorkowski

       lestrrat: Daisuke Maki

       hobbs: Andrew Rodland

       Andy Clayton

       boghead: Bryan Beeley

       Csaba Hetenyi

       Eisuke Oishi

       Lian Wan Situ


       Nick Logan

       Vladimir Timofeev

       diegok: Diego Kuperman

       ijw: Ian Wells

       amiri: Amiri Barksdale

       ozum: Ozum Eldogan

       lukast: Lukas Thiemeier

       Initially based on the source code of Form::Processor by Bill Moseley


       FormHandler Contributors - see HTML::FormHandler


       This software is copyright (c) 2017 by Gerda Shank.

       This is free software; you can redistribute it and/or modify it under the same terms as
       the Perl 5 programming language system itself.