Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
HTML::FormHandler(3)  User Contributed Perl Documentation HTML::FormHandler(3)

       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 presentation.

       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 want.

       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 HTML::FormHandler::Manual.

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

       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' flag:

	  $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'

	  $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'

   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' methods.


       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

       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

	  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

	  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 field.

   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' instead.

	 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 yourself.

       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

       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 'init_object.


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


       See 'language_handle' and '_build_language_handle' in


       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 "borrower".

	  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.

perl v5.32.0			  2017-07-20		  HTML::FormHandler(3)


Want to link to this manual page? Use this URL:

home | help