view release on metacpan or  search on metacpan

lib/Gantry/Docs/FAQ.pod  view on Meta::CPAN

time to log changes or send email to interested (or uninterested) parties.

=item edit_pre_action

Called after form data validation and before changing the data in the
database.  It receives the row object which is about to be changed and a
hash reference of form parameters which are about to become the new
values for that row.  Make your changes in the params hash.  For example,
you could insert a new key:

 sub edit_pre_action {
   my ( $self, $row, $params_hash_ref ) = @_;
     $params_hash_ref{ modified } = 'now';
 }

=item edit_post_action

Called after changing the data in the database with the row object as
amended.  Do whatever you like.  A common pattern is to pair pre and post
actions.  For instance, we have an application which sends email only if
the status field of a row has changed.  Its edit hook methods
look roughly like this:

 sub old_status { # an accessor
     my ( $self, $old_status ) = @_;

     if ( $old_status ) {
         $self->{__OLD_STATUS__} = $old_status;
     }
     return $self->{__OLD_STATUS__};
 }
 sub edit_pre_action { # sets the old_status attribute
     my ( $self, $row, $params_ref ) = @_;

     $self->old_status( $row->status );
 }
 sub edit_post_action { # sends mail if the status changed
     my ( $self, $row ) = @_;

     my $old_status = $self->old_status();
     my $new_status = $row->status;

     if ( $old_status != $new_status ) {
         $self->send_status_mail( $row );
     }
 }

=item delete_pre_action

Called after user confirmation and immediately before the doomed row
is removed from the database.  It receives the row object which is
about to meet its maker.  This is a good place to log its demise
in some other table or die if something has gone awry.

=item delete_post_action

Called immediately after the row has been removed from the database
(commit has already been called).  It receives the id number of the
deceased.  This might be a good place to log the event.

=item get_relocation

Called with the current action (add, edit, or delete) and either submit
or cancel (depending on which button the user pressed).  Return the
url where you want the user to be redirected.

=item get_submit_loc

Ignored if get_relocation is defined.

Called with the current action (add, edit, or delete) and the string 'submit'.
Return the url where you want the user to be redirected.

=item get_cancel_loc

Ignored if get_relocation is defined.

Called with the current action (add, edit, or delete) and the string 'cancel'.
Return the url where you want the user to be redirected.

=back

You may implement as many of these methods as you like in your controller.
Any that are not implemented are simply not called.

=head2 What if AutoCRUD really won't work for me?

While the answer to the last question shows a certain amount of flexibility
in the AutoCRUD scheme, sometimes it just isn't enough.  If you want control,
but don't want to worry with the basics of displaying the form, validating
results, etc. L<Gantry::Plugins::CRUD> is for you.

To have a concrete example, suppose my controller posts comments on a
blog entry, but only if the user is logged in.

Unlike its AutoCRUD counterpart, L<Gantry::Plugins::CRUD> does not export
anything.  Instead it is an object oriented helper.  Here's how it works.
First, use it:

 use Gantry::Plugins::CRUD;

Then make an instance of it, being explicit about what it should do when:

 my $comment_crud = Gantry::Plugins::CRUD->new(
      add_action      => \&add_comment,
      edit_action     => \&edit_comment,
      delete_action   => \&delete_comment,
      form            => \&my_form,
      template        => 'comment_form.tt',
      text_descr      => 'comment',
 );

There are other keys you may use -- see the perldoc for Gantry::Plugins::CRUD
for details.

We'll look at the actions in some detail below.  First, let's examine
the other hash keys here.

The form method must return a single value (usually a hash reference), which
will go to the template that shows the form on the screen.
The text_descr is used when asking the user to confirm a deletion.

All that remains is to implement your own do_ methods to catch the CRUD
requests for your controller.

 do_add {
     my ( $self, $blog_id ) = @_;

     unless ( $self->is_logged_in ) {
         die 'You must log in to post a comment'
     }

     $comment_crud->add( $self, { blog_id = $blog_id } );
 }

If the security check passes, the CRUD plugin's add method will take care of