Gantry::Plugins::AutoCRUD - provides CRUD support
In a base class:
use Gantry qw/-Engine=MP13 -TemplateEngine=Default AutoCRUD/;
Or
use Gantry qw/-Engine=MP13 -TemplateEngine=TT AutoCRUD/;
In your subclass:
use base 'BaseClass'; use Gantry::Plugins::AutoCRUD;
This plugin exports do_add, do_edit, and do_delete for modules which perform straight Create, Update, and Delete (commonly called CRUD, except that R is retrieve which you still have to implement yourself in do_main, do_view, etc.).
This module exports the following methods into the site object's class:
The handler calls these when the user clicks on the proper links or types in the proper address by hand.
In order for these to work, you must implement the required methods from this list yourself:
Return the string which will fill in the blank in the following phrases
Add _____ Edit _____ Delete ____
Optional. The name of the template which generates the form's html. There is a default method provided here, but you can override it. The default always returns 'form.tt'.
The method is called through the site object and passed either 'add' or 'edit', in case you need different forms for these two activities.
If you implement your own, don't import the one provided here (or Perl will warn about subroutine redefinition).
Optional, defaults to
sub get_orm_helper { return 'Gantry::Plugins::AutoCRUDHelper::CDBI'; }
Implement this if you are not using Class::DBI as your ORM. Return the name of your ORM helper. For instance, if you use DBIx::Class implement this in your controller (or in something your controller inherits from):
sub get_orm_helper { return 'Gantry::Plugins::AutoCRUDHelper::DBIxClass'; }
If you need to implement your own helper, see AutoCRUDHelpers below and/or look at any module in Gantry::Plugins::AutoCRUDHelper::* for advice.
Optional. Called with the name of the current action and whether the user clicked submit or cancel like this:
$self->get_relocation( 'add', 'cancel' );
Possible actions are add, edit, or delete. Clicks are either cancel or submit.
Returns the url where users should go if they submit or cancel a form. If defined, this method is used for both submit and cancel actions. This means that get_submit_loc and get_cancel_loc are ignored.
Optional. Called with the action the user is cancelling (add, edit, or delete). Returns the url where users should go if they cancel form submission. Ignored if get_relocation is defined, otherwise defaults to $self->location.
Optional. Called with the action the user is submitting (add, edit, or delete). Returns the url where users should go after they successfully submit a form. Ignored if get_relocation is defined, otherwise defaults to $self->location.
Instead of implementing get_relocation or get_submit_loc, you could implement one or more *_post_action method which alter the location attribute of the self object. Then the default behavior of get_submit_loc would guide you to that location. In this case, you could still implement get_cancel_loc to control where bailing out takes the user.
Return the name of your data model package. If your base class knows this name you might want to do something like this:
sub get_model_name { return $_[0]->companies_model }
This way, the model name is only in one place.
[ For historical reasons, you can name this _form, but that is deprecated and subject to change. ]
Called as a method on your self object with:
the row object from the data model (if one is available)
This describes the entry form for do_add and do_edit. Return a hash with at least a fields key. You can add to this any keys that your template is expecting.
The fields key stores an array reference. The array elements are hashes with at least these keys (your template may be expecting others):
The name of the column in the database table and the field in the web form.
What the user will see as the name of the field on the web form.
Optional. If included and true, the field will be optional. Otherwise, the field will be required.
Optional. Any valid Data::FormValidator constraint.
Remember that your template may be expecting other keys like type, display_size, default_value, date_select and others that vary by type.
The default template in the sample apps uses options for select types and both rows and cols for textarea types.
sub add_pre_action { my ( $self, $params ) = @_; ... }
Optional. Called immediately before a new row is inserted into the database with the hash that will be passed directly to the ORM helper's insert method. Adjust any parameters in the hash you like (fill in dates, remove things that can't have '' as a value, etc.).
sub add_post_action { my ( $self, $new_row ) = @_; ... }
Optional. Called immediately after a new row has been inserted (and committed) into the database with the newly minted row object. This is a useful place to make change log entries, send email, etc.
sub edit_pre_action { my ( $self, $row, $params ) = @_; ... }
Optional. Like add_pre_action, but receives the row to be updated and the params hash that is about to be set on it.
sub edit_post_action { my ( $self, $row, $params ) = @_; ... }
Optional. Just like add_post_action, but for edit.
sub delete_pre_action { my ( $self, $row, $params ) = @_; ... }
Optional. Called just before a row is removed from the database with the row object.
sub delete_post_action { my ( $self, $row, $params ) = @_; ... }
Optional. Called just after a row has been removed from the database with the former row's id.
These are methods used internally to figure out where to go on button presses and who should help the ORM manage the database.
If there is not a Gantry::Plugins::AutoCRUD::* module for your ORM, you can easily implement your own. Here's how.
Create a module (the name is completely up to you, but something in the Gantry::Plugins::AutoCRUD:: namespace may be easier for others to find). In it implement four methods:
Parameters: $class - invoking class name $gantry_site_object - the current Gantry site object $params - a hash to be inserted into a new row Return: the newly created row
Puts a new row into a table of the database. You must determine the table name by querying $gantry_site_object. For instance, if the app uses CDBI models, your table name is:
$gantry_site_object->get_model_name
For DBIx::Class models, your table name is:
$gantry_site->get_model_name->table_name();
Parameters: $class - invoking class name $gantry_site_object - the current Gantry site object $id - the primary key of a row (single column only) Return: the row whose id is $id
Given a unique one column primary key, called $id, return the corresponding row. See the discussion under insert for how to find your table name.
Parameters: $class - invoking class name $gantry_site_object - the current Gantry site object $row - the row object to update $params - a hash to be inserted into a new row Return: whatever you like (ignored)
Given an ORM object, update the underlying data.
Parameters: $class - invoking class name $gantry_site_object - the current Gantry site object $row - the row object to update Return: whatever you like (ignored)
Given an ORM object, delete the underlying row.
Gantry::Plugins::AutoCRUD::CDBI Gantry::Plugins::AutoCRUD::DBIxClass Gantry::Plugins::CRUD The Billing sample app Gantry and the other Gantry::Plugins
These methods only work one way. If you need more flexibility, you will have to code your own method and nothing here will help you (but Gantry::Plugins::CRUD might).
The idea is to do the work for the 60-80% of your modules which manage data in one table one row at a time, leaving you to work on the ones that are more interesting.
Phil Crow <philcrow2000@yahoo.com>
Copyright (c) 2005, Phil Crow
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.6 or, at your option, any later version of Perl 5 you may have available.
To install Gantry, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Gantry
CPAN shell
perl -MCPAN -e shell install Gantry
For more information on module installation, please visit the detailed CPAN module installation guide.