BeerFB->config->model( 'Maypole::FormBuilder::Model' );

Major surgery

This class does not inherit from Maypole::Model::CDBI, for several reasons. We don't need to load Class::DBI::Untaint, Class::DBI::AsForm or Class::DBI::FromCGI. I wanted to implement a config option to choose which pager to use (see do_pager). And I wanted to rename methods that share a name with methods in Class::DBI (delete and search are now do_delete and do_search).

Maypole is pretty stable these days and it should be easy enough to keep up with any bug fixes.



This method is responsible for ensuring that the 'server' form and the 'client' form are equivalent - see Coordinating client and server forms.

Returns a form spec for the selected form mode. The mode defaults to $r->action. You can set a different mode in the args hash to the as_form call.

Override this in model classes to configure custom modes, and call

    $proto->SUPER::setup_form_mode( $r, $args )

in the custom method if it doesn't know the mode.

You can add a mode_args argument to the hashref of arguments that reach setup_form_mode. For instance, the addto template uses this to pass

Modes supported here are:

    ${action}_button    where $action is any public action on the class

Column and field lists

Standard Maypole defines a few methods to return different lists of columns and column-like accessors (display_columns, list_columns, and related). Several more methods are added here, and are used in the templates, but in general they will default to return the same list as one of the standard methods.

The rationale is that in general, each template may need to display a different view of the object(s) (edit, view, list, search etc.). Your own templates can use these methods, and you will probably want to define additional column/field listing methods in your custom models and templates.

Each *_columns method has a matching <*_fields> method, which can be used to add non-column fields (i.e. has_many accessors) to the relevant form. (For display_columns, the relevant fields method is related).


Returns a list of columns, minus primary key columns, which probably don't need to be displayed. The templates use this as the default list of columns to display.

Note that Class::DBI::FormBuilder will add back in hidden fields for the primary key(s), to support lookups done in several of its *_from_form methods.


Defaults to related().

Returns a list of accessors for has_many related classes. These can appear as fields in a form, but are not columns in the database.


This method is not defined here, but in Maypole::Model::Base, and defaults to display_columns. This is used to define the columns displayed in the list template.


Defaults to related.

The list template uses list_columns plus list_fields as the default list of fields to display, and setup_form_mode sets list_columns plus list_fields in the fields argument in editlist mode, so that editable and navigable list views both present the same fields.


Used to build the search form. Defaults to display_columns.


Used to build the search form. Defaults to an empty list.


Defaults to display_columns.


Defaults to related. Used in the edit template to display values of has_many fields and build separate forms for adding more items to a has_many.


Defaults to display_columns.


Defaults to empty list, at least until I add addmany support to addnew.


Counterpart to MP::Model::Base::column_names. Returns a hash of field names to field labels.


Same interface as CGI's param method, except read-only, for the moment.

Useful for example with HTML::FillInForm:

    my $cd = My::Music::CD->retrieve( $id );
    # $html contains an empty form
    $html = HTML::FillInForm->new->fill( scalarref => \$html, fobject => $cd );

Note that this method always returns scalars. For columns that inflate to non-CDBI objects, the object is evaluated in string context. For columns that inflate to a CDBI object, the raw column value is returned instead.

Exported methods

Exported methods have the Exported attribute set. These are the methods that URLs can trigger. See the main Maypole documentation for more information.

As a convenience and a useful convention, all these methods now set the appropriate template, so it shouldn't be necessary to set the template and then call the method. This is particularly useful in despatching methods, such as editlist.

Some exported methods are defined in Maypole::FormBuilder::Model::Base, if they have no dependency on CDBI. But the likelihood of a FormBuilder distribution that doesn't depend on Class::DBI::FormBuilder is pretty low.


The way CGI::FormBuilder handles different button clicks (i.e. it handles them), means we need a separate method for creating new objects (in standard Maypole, addnew posts to do_edit). But Class::DBI::FormBuilder keeps things simple.

Note this method returns to the edit template, which is useful in some situations, but for many apps, you probably want to return the user to the view template instead. Simply override addnew in your model, perhaps calling $self->SUPER::addnew to perform the update, then return vis $self->view( $r ).


Adds a new item in a has_many relationship.


Receives the number of requested items and forwards to the addmany template.


Add several items to the target, where <target_class has_many items>.


Sets the edit template.

Also sets the action to edit. This is necessary to support forwarding to the edit template from the edit button on the editlist template.


Implements update operations on submitted forms.

Runs a search_where search.

Does not implement search ordering yet, and there are various other modifications that could make this better, such as allowing LIKE comparisons (% and _ wildcards) etc.


Detects which submit button was clicked, and despatches to the appropriate method.


Does not implement ordering yet.


Deletes a single object.


Just sets the view template.


If sessions are enabled, this switches the default list mode between editlist and list.


Basic support for the editrelated template. This is currently under development in Class::DBI::FormBuilder::as_form_with_related().

Coordinating client and server forms

Every form is used in two circumstances, and the forms must be built with equivalent properties in each. In the first, a form object is constructed and used to generate an HTML form to be sent to the client. In the second, a form object is constructed and is used to receive data sent in a form submission from the client. These may be loosely termed the 'server' and 'client' forms (although they are both built on the server).

The forms built in these two situations must have equivalent properties, such as the same field lists, the same option lists for multi-valued fields, etc.

The point of co-ordination is the setup_form_mode method. This supplies the set of characteristics that must be synchronised by both versions of the form. setup_form_mode selects a set of form parameters based on the current action of the Maypole request.


form mode

Sometimes you need to set the form mode in these methods, sometimes not. If the mode matches the action, you don't need to set it. So to get searching working, the do_search mode needs to be set. Similarly for do_edit, except here the edit mode needs to be set. Elsewhere the mode is automatically set to the Maypole action.

submit button name

If you insert a line in CGI::FormBuilder::submitted() to warn the value of $smtag, that needs to match the name of the submit button in $request->params (i.e. $request->params->{$smtag} needs to be true).

Maypole::Model::CDBI methods

These methods are copied verbatim from Maypole::Model::CDBI. See that module for documentation.


The default pager is Class::DBI::Pager. Use a different pager by setting the pager_class config item:

    BeerFB->config->pager_class( 'Class::DBI::Plugin::Pager' );

This method is not used in the Maypole::Plugin::FormBuilder templates at the moment. Probably, ordering will be implemented directly in Class::DBI::FormBuilder and this method can disappear.



David Baird, <>


I think splitting modes into search and do_search, and edit and do_edit, is probably unnecessary.

Pairs of methods like search and do_search, edit and do_edit are probably unnecessary, as FB makes it easy to distinguish between rendering a form and processing a form - see editrelated().


Please report any bugs or feature requests to, or through the web interface at I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.


Copyright 2005 David Baird, All Rights Reserved.

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