The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.
 / 
Gantry-3.20
River stage one • 3 direct dependents • 3 total dependents
2 ++
/ Gantry::Plugins::AutoCRUD

NAME

Gantry::Plugins::AutoCRUD - provides CRUD support

SYNOPSIS

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;

DESCRIPTION

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.).

METHODS

This module exports the following methods into the site object's class:

do_add
do_edit
do_delete

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:

text_descr

Return the string which will fill in the blank in the following phrases

        Add _____
        Edit _____
        Delete ____
form_name

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).

get_relocation

Optional. Called with the name of the current action and whether the user clicked submit or cancel. Example:

    $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.

get_cancel_loc

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>>.

get_submit_loc

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.

get_model_name

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.

form

[ 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):

name

The name of the column in the database table and the field in the web form.

label

What the user will see as the name of the field on the web form.

optional

Optional. If included and true, the field will be optional. Otherwise, the field will be required.

constraint

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.

add_pre_action

Optional. Called immediately before a new row is inserted into the database with the hash that will be passed directly to Class::DBI's create method for the table. Adjust any parameters in the hash you like (fill in dates, remove things that can't have '' as a value, etc.).

add_post_action

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.

edit_pre_action

Optional. Like add_pre_action, but receives the row to be updated and the params hash that is about to be set on it.

edit_post_action

Optional. Just like add_post_action, but for edit.

delete_pre_action

Optional. Called just before a row is removed from the database with the row object.

delete_post_action

Optional. Called just after a row has been removed from the database with the former row's id.

SEE ALSO

 Gantry::Plugins::CRUD

 The Billing sample app

 Gantry and the other Gantry::Plugins

LIMITATIONS

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.

AUTHOR

Phil Crow <philcrow2000@yahoo.com>

COPYRIGHT and LICENSE

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.