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

FreeBSD Manual Pages


home | help

       HTML::FormHandler::TraitFor::Model::DBIC	- model	role that interfaces
       with DBIx::Class

       version 0.29

       Subclass	your form from HTML::FormHandler::Model::DBIC:

	   package MyApp::Form::User;
	   use HTML::FormHandler::Moose;
	   extends 'HTML::FormHandler::Model::DBIC';

       or apply	as a role to FormHandler class:

	  package MyApp::Form::User;
	  use HTML::FormHandler::Moose;
	  extends 'HTML::FormHandler';
	  with 'HTML::FormHandler::TraitFor::Model::DBIC';

       This is a separate DBIx::Class model role for HTML::FormHandler.	 It
       will handle normal DBIC column accessors	and a number of	DBIC
       relationships.  It will save form fields	automatically to the database.
       The distribution	contains a form	generator
       (HTML::FormHandler::Generator::DBIC). An	example	application can	be
       found on	github at

       HTML::FormHandler::TraitFor::DBICFields can be used to auto-generate
       forms from a DBIC result.

	   my $book = $schema->resultset('Book')->find(1);
	   my $form = HTML::FormHandler::Model::DBIC->new_with_traits(
	      traits =>	['HTML::FormHandler::TraitFor::DBICFields'],
	      field_list => [ 'submit' => { type => 'Submit', value => 'Save', order =>	99 } ],
	      item => $book );

       This model supports using DBIx::Class result_source accessors just as
       if they were standard columns.  Forms that need to do custom updating
       usually will subclass or	use an 'around'	method modifier	on the
       'update_model' method.

       There are two ways to get a valid DBIC model. The first way is to set:

	  item_id (primary key)
	  item_class (source name)

       The 'item_class'	is usually set in the form class:

	   # Associate this form with a	DBIx::Class result class
	   has '+item_class' =>	( default => 'User' ); # 'User'	is the DBIC source_name

       The 'item_id' and 'schema' must be passed in when the form is used in
       your controller.

	  $form->process( item_id => $id, schema => $c->model('DB')->schema,
			  params => $c->req->params );

       If the item_id is not defined, then a new record	will be	created.

       The second way is to pass in a DBIx::Class row, or 'item';

	  $form->process( item => $row,	params => $c->req->params );

       The 'item_id', 'item_class', and	'schema' will be derived from the
       'item'.	For a new row (such as on a 'create' ),	you can	use

	  my $item = $c->model('DB::Book')->new_result({});
	  $form->process( item => $item, params	=> $c->req->params );

       The accessor names of the fields	in your	form should match column,
       relationship, or	accessor names in your DBIx::Class result source.
       Usually the field name and accessor are the same, but they may be

DBIC Relationships
       Single Select fields will handle	'belongs_to' relationships, where the
       related table is	used to	construct a selection list from	the database.

       Multiple	Select fields use a 'many_to_many' pseudo-relation to retrieve
       the selection list from the database.

	  has_field 'roles' => (
	     type => 'Multiple',
	     label_column => 'role',

       You need	to supply 'label_column' to indicate which column should be
       used as label.

       A Compound field	can represent a	single relation. A Repeatable field
       will map	onto a multiple	relationship.

       More information	is available from:




       Stores the schema that is either	passed in, created from	the model name
       in the controller, or created from the Catalyst context and the
       item_class in the plugin.

       The place to put	validation that	requires database-specific lookups.
       Subclass	this method in your form. Validation of	unique fields is
       called from this	method.

       Updates the database. If	you want to do some extra database processing
       (such as	updating a related table) this is the method to	subclass in
       your form.

       This routine allows the use of non-database (non-column,	non-
       relationship) accessors in your result source class. It identifies form
       fields as column, relationship, select, multiple, or other. Column and
       other fields are	processed and update is	called on the row. Then
       relationships are processed.

       If the row doesn't exist	(no primary key	or row object was passed in),
       then a row is created.

       This method is used with	"Single" and "Multiple"	field select lists
       ("single", "filter", and	"multi"	relationships).	 It returns an array
       reference of key/value pairs for	the column passed in.  The column name
       defined in $field->label_column will be used as the label.  The default
       label_column is "name".	The labels are sorted by Perl's	cmp sort.

       If there	is an "active" column then only	active values are included,
       except if the form (item) has currently selected	the inactive item.
       This allows existing records that reference inactive items to still
       have those as valid select options.  The	inactive labels	are formatted
       with brackets to	indicate in the	select list that they are inactive.

       The active column name is determined by calling:
	   $active_col = $form->can( 'active_column' )
	       ? $form->active_column
	       : $field->active_column;

       This allows setting the name of the active column globally if your
       tables are consistantly named (all lookup tables	have the same column
       name to indicate	they are active), or on	a per-field basis.

       The column to use for sorting the list is specified with	"sort_column".
       The currently selected values in	a Multiple list	are grouped at the top
       (by the Multiple	field class).

       This method sets	a field's initial value. it is set when	values are
       initially loaded	from an	item, init_object or field defaults.

       For fields that are marked "unique", checks the database	for
       uniqueness.  The	unique constraints registered in the DBIC result
       source (see "add_unique_constraint" in DBIx::Class::ResultSource) will
       also be inspected for uniqueness	unless the field's 'unique' attribute
       is set to false.	 Alternatively,	you can	use the	"unique_constraints"
       attribute to limit uniqueness checking to only a	select group of	unique
       constraints.  Error messages can	be specified in	the "unique_messages"
       attribute.  Here's an example where you might want to specify a unique
       widget name for a given department:

	  has '+unique_constraints' => ( default => sub	{ ['department_widget_name'] } );
	  has '+unique_messages' => (
	     default =>	sub {
		{ department_widget_name => "Please choose a unique widget name	for this department" };

       Returns a DBIx::Class::ResultSource object for this Result Class.

       This method returns a resultset from the	"item_class" specified in the
       form ("$schema->resultset( $form->item_class )")

	   DBIx::Class::ResultSet::RecursiveUpdate is used to interface	with
	   DBIx::Class.	 By default, the flag 'unknown_params_ok' is passed
	   in. The 'ru_flags' attribute	is a hashref, and also provides

       FormHandler Contributors	- see HTML::FormHandler

       This software is	copyright (c) 2013 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			  2HTML::FormHandler::TraitFor::Model::DBIC(3)


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

home | help