Jason Purdy > CGI-Application-Plugin-BREAD-0.12_2 > CGI::Application::Plugin::BREAD

Download:
CGI-Application-Plugin-BREAD-0.12_2.tar.gz

Dependencies

Annotate this POD

Module Version: 0.12_2   Source  

NAME ^

CGI::Application::Plugin::BREAD - Plugin for Dynamic Database Management Application

Description

A lot of emphasis has been put on Ruby on Rails, Catalyst or other type of easy-to-use and easy-to-setup BREAD applications. BREAD (oh how we love acronyms) stands for Browse, Read, Edit, Add and Delete. CRUD (Create, Retrieve, Update and Delete) also suffices, but BREAD just sounds better. Either way you slice it (pun intended), this Plugin will allow you to setup a database management tool for your users in no time.

Synopsis

The instance script stays the same.

In your CGI::Application module:

  package MyBREADApp;

  use base 'CGI::Application';
  use CGI::Application::Plugin::BREAD qw( bread_db );
  use Class::DBI::Loader;

  sub setup
  {
    $self = shift;
    my $loader = Class::DBI::Loader->new(
            dsn                     => "dbi:mysql:mysql",
            user                    => "webuser",
            password                => "webpass",
            namespace               => "WHATEVER",
            relationships           => 1,
            additional_classes      => [ 'Class::DBI::FormBuilder' ],
        );
    $self->bread_db( $loader );
  }

Details

Then just point your browser to your instance script and you can use the following URL patterns:

http://example.com/mybreadapp.cgi
http://example.com/mybreadapp.cgi?rm=browse_users
http://example.com/mybreadapp.cgi?rm=read_users&id=5
http://example.com/mybreadapp.cgi?rm=edit_users&id=5
http://example.com/mybreadapp.cgi?rm=add_users
http://example.com/mybreadapp.cgi?rm=delete_users&id=5

The patterns follow a standardized set of prefixes (browse_, read_, edit_, add_ and delete_) and then the name of the table (in the example above, users).

This module doesn't deal with authentication (yet) -- if you want to protect the application, it's recommended that you place the instance script in a secured directory or Apache Directive. We foresee adding more microlevels of authentication, such that you can define which users can delete, add, edit, etc.

This module comes with some rudimentary templates that are built-in, just in case you want a simplified approach and don't really care about the look & feel. If this needs more polish, you can override the built-in templates with your own template files. The plugin will automatically look for any overriding template files in the local directory and then also in a templates subdirectory. Optionally, you can also point the BREAD plugin to a directory where your own templates reside. Template files must match the runmode names. So the plugin will look for browse_users.TMPL (which can be an HTML::Template, Template::Toolkit or Petal)

This module can automatically log any work done. Unless you specify some logging directives, it will append to a temp file called bread_YYMMDD.log. Otherwise, you can specify a logging directive in your cgiapp_init (or setup) method, which follows the LogDispatch technique.

bread_db

This method points the BREAD plugin to what database to work with. There's a lot of flexibility in the parameter choices. You can provide an array reference of Class::DBI classes or Class::DBI::Loader. This method will inspect your parameter by looking at its reference.

browse_page_size

Optional configuration method in which you can override the default page size of 20 records.

template_path (NOT YET IMPLEMENTED)

Totally optional - if you specify this, the plugin will also look for an overriding template file in the directory that you specify here. The method expects a simple scalar parameter.

template_type (NOT YET IMPLEMENTED)

Again, totally optional. If you're going to override the built-in templates and if you're going to not use the HTML::Template default, then you can specify the template type by giving a parameter of 'TemplateToolkit' or 'Petal'. These parameters get passed into the CGI::Application::Plugin::AnyTemplate, so if their parameters change in the future, so will these.

log_directive (NOT YET IMPLEMENTED)

Another optional directive. This parameter shares the same from CGI::Application::Plugin::LogDispatch, so the parameter matches that specification.

See Also ^

CGI::Application, HTML::Template, Template::Toolkit, Petal.pm, DBI.pm, Class::DBI, Class::DBI::Loader

http://www.cgi-app.org CGI::Application Wiki

DEVELOPMENT ^

This software is managed with darcs (http://www.darcs.net). You can get the repository here with darcs:

http://www.purdy.info/darcs/cap-bread

Or browse it via the web:

http://www.purdy.info/cgi-bin/darcs.cgi/cap-bread/?c=browse

You can discuss this module on cgi-app@lists.erlbaum.net or #cgiapp on irc.perl.org.

BUGS ^

This release is "alpha" - please do not use this in a production environment until we reach version 1.0. This release is meant to gather feedback and keep our momentum going.

Post bugs to the RT:

http://rt.cpan.org/NoAuth/Bugs.html?Dist=CGI-Application-Plugin-BREAD

AUTHORS ^

Jason Purdy, <jason@purdy.info> Mark Stosberg <mark@summersault.com>

LICENSE ^

Copyright (C) 2005 Jason Purdy, <jason@purdy.info>

This library is free software. You can modify and or distribute it under the same terms as Perl itself.

syntax highlighting: