view release on metacpan or  search on metacpan

lib/Bigtop/Docs/Cookbook.pod  view on Meta::CPAN

    sub empty {
        my ( $self, $id ) = @_;
    }

(Note that extra_args is optional.)

You then fill in the operative bits.

Note that adding stub methods to your Bigtop file once your stub module
exists will have no effect, since regeneration never alters existing stubs.
To force generation rename or delete the stub module.

=head2 How do I use Gantry's AutoCRUD?

Gantry's AutoCRUD supplies do_add, do_edit, and do_delete for simple
tables.  To use it say

    controller Simple is AutoCRUD {
        method form is AutoCRUD_form {
            form_name simple
            fields    name, address;
            extra_keys
                legend => `$self->path_info =~ /edit/i ? 'Edit' : 'Add'`;
        }
    }

This makes the following stub:

    package Apps::AppName::Simple;

    use strict;

    use base 'Apps::AppName';
    use Apps::AppName::GEN::Simple qw(
        form
    );

    use Gantry::Plugins::AutoCRUD qw(
        do_add
        do_edit
        do_delete
        form_name
    );

    #-----------------------------------------------------------------
    # $self->form( $row )
    #-----------------------------------------------------------------
    # This method supplied by Apps::Checkbook::GEN::Trans

Bigtop makes a note in the stub for each method it is mixing in from
the GEN module.

Note that both the GEN module and Gantry::Plugins::AutoCRUD are mixins (they
export methods).  If you don't want their standard methods, don't include
them in the import lists.  But, if you don't want the ones from
Gantry::Plugins::AutoCRUD, you probably want real CRUD (see below).

=head2 How do I use Gantry's CRUD?

Gantry's AutoCRUD has quite a bit of flexibility (e.g. it has pre and post
callbacks for add, edit, and delete), but sometimes it isn't enough.
Even when it is enough, some people prefer explicit schemes to implicit
ones.  CRUD is more explicit.  To use it do this:

    controller NotSoSimple is CRUD {
        text_description `Not So Simple Item`;
        method my_crud_form is CRUD_form {
            form_name simple
            fields    name, address;
            extra_keys
                legend => `$self->path_info =~ /edit/i ? 'Edit' : 'Add'`;
        }
    }

There are only a couple of differences from the AutoCRUD version above.  The
controller type is just CRUD; the form method is called my_crud_form and
has type CRUD_form.

Note that it is important to use a method name that ends in _form, but
don't use just _form.  The backend says:

    my ( $crud_name = $method_name ) =~ s/_form$//;

So using _form as the name (which is required for AutoCRUD) will make
Bad Things happen for CRUD.

The above produces a lot of code.  I'll show it a piece at a time with
running commentary interspersed.  It makes a CRUD object:

    my $my_crud = Gantry::Plugins::CRUD->new(
        add_action      => \&my_crud_add,
        edit_action     => \&my_crud_edit,
        delete_action   => \&my_crud_delete,
        form            => \&my_crud_form,
        redirect        => \&my_crud_redirect,
        text_descr      => 'Not So Simple Item',
    );

It makes do_add, do_edit, and do_delete.  For example:

    #-------------------------------------------------
    # $self->do_add( )
    #-------------------------------------------------
    sub do_add {
        my $self = shift;

        $my_crud->add( $self, { data => \@_ } );
    }

(do_edit and do_delete are similar.)

Finally, it provides the callbacks.  For example:

    #-------------------------------------------------
    # $self->my_crud_add( $id )
    #-------------------------------------------------
    sub my_crud_add {
        my ( $self, $params, $data ) = @_;

        # make a new row in the $YOUR_TABLE table using data from $params
        # remember to commit
    }

It also makes my_crud_edit, my_crud_delete, and my_crud_redirect.
Note that you don't get actual code for updating your database, just
comments telling you what normal people do.  Of course, abnormality is
one of the main reasons for using CRUD instead of AutoCRUD, so take
the comments with a grain of salt.

Note that if you have more than one method of type CRUD_form, the bigtop
backend will make multiple crud objects (each named for its form)
and the callbacks for those objects.  But it will also make multiple
do_add, do_edit, and do_delete methods.  They will make their calls through
the proper crud object, but their names will be duplicated.  In that
case, you are on your own to change them to reasonable (i.e. non-clashing)
names.

=head1 Using Gantry's ORM Help

=head2 What does the GantryDBIxClass Model backend make?

The Model GantryDBIxClass backend makes a pair of modules for each table.
One is the stub module, the other is the GEN module.  Once made, the
stub is never regenerated, so put your code in it.  The GEN module
will be regenerated when you run bigtop.

    config {
        #...
        Model GantryDBIxClass {}
    }
    app Apps::Name {
        table some_table {
            #...
        }
    }

This makes Apps::Name::Model::some_table (the stub) and
Apps::Name::Model::GEN::some_table (the GEN module).  Note that the
names are exactly the same as the table name.  If you want capital
letters, use them to name the table.

Due to the way that DBIx::Class binds the methods it makes on the fly, the GEN
module mixes in to the stub by using this to start its file:

    package Apps::Name::Model::some_table;

So, the disk file is named Apps/Name/Model/GEN/some_table.pm, but
the package statement is the same as the one in the stub.  This will cause
sub redefinition warnings, if you put a sub in the stub with the same
name as one in the GEN module.  Models generated by Model Gantry inherit
from Gantry::Utils::Model, which allows inheritence instead of mixing in.
These are the native models.

In addition to regular tables, the Model GantryDBIxClass backend understands
the join_table block (which became available in version 0.15).  Join tables
are needed to support many-to-many relationships like this:

    +-----+           +-------+
    | job |<-+     +->| skill |
    +-----+  |     |  +-------+
             |     |
          +-----------+
          | job_skill |
          +-----------+

To express this, add:

    join_table job_skill {
        joins job => skill;
    }

This will have serveral effects.  First, all SQL backends will make the