legend results from the CPAN

legend
CGI-FormBuilder
view release on metacpan or search on metacpan
lib/CGI/FormBuilder.pod view on Meta::CPAN
=over

=item action => $script

What script to point the form to. Defaults to itself, which is
the recommended setting.

=item body => \%attr

This takes a hashref of attributes that will be stuck in the
C<< <body> >> tag verbatim (for example, bgcolor, alink, etc).
See the C<fieldattr> tag for more details, and also the
C<template> option.

=item charset

This forcibly overrides the charset. Better handled by loading
an appropriate C<messages> module, which will set this for you.
See L<CGI::FormBuilder::Messages> for more details.

=item debug => 0 | 1 | 2 | 3

If set to 1, the module spits copious debugging info to STDERR.
If set to 2, it spits out even more gunk. 3 is too much. Defaults to 0.

=item fields => \@array | \%hash

As shown above, the C<fields> option takes an arrayref of fields to use
in the form. The fields will be printed out in the same order they are
specified. This option is needed if you expect your form to have any fields,
and is I<the> central option to FormBuilder.

You can also specify a hashref of key/value pairs. The advantage is
you can then bypass the C<values> option. However, the big disadvantage
is you cannot control the order of the fields. This is ok if you're
using a template, but in real-life it turns out that passing a hashref
to C<fields> is not very useful.

=item fieldtype => 'type'

This can be used to set the default type for all fields in the form.
You can then override it on a per-field basis using the C<field()> method.

=item fieldattr => \%attr

This option allows you to specify I<any> HTML attribute and have it be
the default for all fields. This used to be good for stylesheets, but
now that there is a C<stylesheet> option, this is fairly useless.

=item fieldsets => \@attr

This allows you to define fieldsets for your form. Fieldsets are used
to group fields together. Fields are rendered in order, inside the
fieldset they belong to. If a field does not have a fieldset, it
is appended to the end of the form.

To use fieldsets, specify an arrayref of C<< <fieldset> >> names:

    fieldsets => [qw(account preferences contacts)]

You can get a different C<< <legend> >> tag if you specify a nested arrayref:

    fieldsets => [
        [ account  => 'Account Information' ],
        [ preferences => 'Website Preferences' ],
        [ contacts => 'Email and Phone Numbers' ],
    ]

If you're using the source file, that looks like this:

    fieldsets: account=Account Information,preferences=...

Then, for each field, specify which fieldset it belongs to:

    $form->field(name => 'first_name', fieldset => 'account');
    $form->field(name => 'last_name',  fieldset => 'account');
    $form->field(name => 'email_me',   fieldset => 'preferences');
    $form->field(name => 'home_phone', fieldset => 'contacts');
    $form->field(name => 'work_phone', fieldset => 'contacts');

You can also automatically create a new C<fieldset> on the fly by
specifying a new one:

    $form->field(name => 'remember_me', fieldset => 'advanced');

To set the C<< <legend> >> in this case, you have two options.
First, you can just choose a more readable C<fieldset> name:

    $form->field(name => 'remember_me',
                 fieldset => 'Advanced');

Or, you can change the name using the C<fieldset> accessor:

    $form->fieldset(advanced => 'Advanced Options');

Note that fieldsets without fields are silently ignored, so you can
also just specify a huge list of possible fieldsets to C<new()>, and
then only add fields as you need them.

=item fieldsubs => 0 | 1

This allows autoloading of field names so you can directly access
them as:

    $form->$fieldname(opt => 'val');

Instead of:

    $form->field(name => $fieldname, opt => 'val');

Warning: If present, it will hide any attributes of the same name.
For example, if you define "name" field, you won't be able to 
change your form's name dynamically. Also, you cannot use this
format to create new fields. Use with caution.

=item font => $font | \%attr

The font face to use for the form. This is output as a series of
C<< <font> >> tags for old browser compatibility, and will 
properly nest them in all of the table elements. If you specify
a hashref instead of just a font name, then each key/value pair
will be taken as part of the C<< <font> >> tag:

    font => {face => 'verdana', size => '-1', color => 'gray'}

The above becomes:

    <font face="verdana" size="-1" color="gray">

I used to use this all the time, but the C<stylesheet> option
is B<SO MUCH BETTER>. Trust me, take a day and learn the basics
of CSS, it's totally worth it.

=item header => 0 | 1

If set to 1, a valid C<Content-type> header will be printed out,
along with a whole bunch of HTML C<< <body> >> code, a C<< <title> >>
tag, and so on. This defaults to 0, since often people end up using
templates or embedding forms in other HTML.

=item javascript => 0 | 1

If set to 1, JavaScript is generated in addition to HTML, the
default setting.

=item jserror => 'function_name'
( run in 1.472 second using v1.01-cache-2.11-cpan-0bb4e1dffa6 )