Class-DBI-FormBuilder
view release on metacpan or search on metacpan
lib/Class/DBI/FormBuilder.pm view on Meta::CPAN
use Class::DBI::FormBuilder;
# for indented output:
# use Class::DBI::FormBuilder PrettyPrint => 'ALL';
# POST all forms to server
Film->form_builder_defaults->{method} = 'post';
# customise how some fields are built:
# 'actor' is a has_a field, and the
# related table has 1000's of rows, so we don't want the default popup widget,
# we just want to show the current value
Film->form_builder_defaults->{process_fields}->{actor} = 'VALUE';
# 'trailer' stores an mpeg file, but CDBI::FB cannot automatically detect
# file upload fields, so need to tell it:
Film->form_builder_defaults->{process_fields}->{trailer} = 'FILE';
# has_a fields will be automatically set to 'required'. Additional fields can be specified:
Film->form_builder_defaults->{required} = qw( foo bar );
lib/Class/DBI/FormBuilder.pm view on Meta::CPAN
and C<might_have> relationships. Further relationships can be added by subclassing. C<has_a> columns
are set as 'required' fields in create/update forms.
A demonstration app (using L<Maypole::FormBuilder|Maypole::FormBuilder>) can be viewed at
http://beerfb.riverside-cms.co.uk
=head1 Customising field construction
Often, the default behaviour will be unsuitable. For instance, a C<has_a> relationship might point to
a related table with thousands of records. A popup widget with all these records is probably not useful.
Also, it will take a long time to build, so post-processing the form to re-design the field is a
poor solution.
Instead, you can pass an extra C<process_fields> argument in the call to C<as_form> (or you can
set it in C<form_builder_defaults>).
Many of the internal routines use this mechanism for configuring fields. A manually set '+'
(basic) processor will be B<added> to any other automatic processing, whereas a manually set shortcut
processor (no '+') will B<replace> all automatic processing.
( run in 2.451 seconds using v1.01-cache-2.11-cpan-364913b4093 )