George,
Below is my own rewrite of your setup() routine. This isn't a drop-in
replacement, but assumes some a few stylistic changes elsewhere in the
code. Some other suggestions:
* I think it makes sense to have a "Delete" run mode, but perhaps not a
"Delete" screen, unless it's a confirmation screen. I handle this by
sticking a "Delete" button on the update screen, which activates the
Delete run mode. You can use some simple JavaScript on the button for a
confirmation:
onClick="return confirm('Really Delete?')"
* You might look at some existing projects that have already addressed
web/db CRUD. A simple solution is DB_Browser (
http://www.summersault.com/softare/db_browser ), which supports MySQL,
Postgres, and Oracle, as well as HTML::Template. It does not include
"next record, previous record" features as you describe, but you could
add that.
On the more complex end, their's Cascade (
http://summersault.com/software/cascade ), which is based on CGI::App,
and more of a complete content management solution rather than just a
CRUD interface. ( and may not run under Windows).
-mark
# Assumption: run mode can be determined by looking at the "rm" cgi
# field, either through a query string or a form button
sub setup {
my $self = shift;
# define default mode
$self->start_mode('Create');
# use $self->query() instead
# $self->param('cgi' => $cgi);
$self->param('buttons' => [qw(Create Read Update Delete)]);
# Do you need this, or can your just check to see what subroutine
# you are in?
$self->param('crudMode' => $crudMode);
# If you don't want the user to tamper with these,
# You could define them in the instance script through param()
# rather than through CGI
# (or in a seperate config file, which could also be used via
# cron)
# Data structure containing database, hidden field and template
# information
$self->param('appDefs' => AutoDefine($cgi));
$self->run_modes(
Create => 'Create',
Update => 'Update',
Delete => 'Delete',
Read => 'Read',
# can't find a run mode? Abort
AUTOLOAD => 'Abort',
);
}
On Fri, 28 Dec 2001, George Jempty wrote:
> --- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> >
> > George,
> >
> > I started to critique this, but ran into several
> > questions. Could you
> > additionally post the "plain English" version of
> > what this supposed to
> > do? (and consider including the less clear parts of
> > that directly in
> > code documentation).
> >
> > Thanks,
> >
> > -mark
> >
> > George Jempty wrote:
> > >
> > > First off, thanks to everybody who has helped me
> > on
> > > this group thus far. I'm lacking in both
> > experience,
> > > but especially resources, so am trying to sell
> > > management on the use of CGI::Application, if only
> > for
> > > the informal support available here.
> > >
> > > I'd like feedback on my setup method. At present
> > it
> > > looks like:
> > >
> > > #
> > > sub setup
> > > {
> > > my $self = shift;
> > > my $cgi = $self->query();
> > >
> > > my @crudButtons = qw(create read update delete);
> > > my $defaultMode = 'create';
> > >
> > > my $crudMode = GetSubmitName(\@crudButtons,
> > > $cgi->Vars) || $defaultMode;
> > > my $crudCall = sub {return $crudMode};
> > >
> > > my $selfState = AutoStatus();
> > >
> > > $self->mode_param($crudCall);
> > >
> > > $self->param('cgi' => $cgi);
> > > $self->param('crud_buttons' => \@crudButtons);
> > > $self->param('crud_mode' => $crudMode);
> > > $self->param('state' => $selfState);
> > >
> > > foreach my $button (@crudButtons)
> > > {
> > > $self->run_modes($button => \&$button);
> > > }
> > > }
> > > #
> > >
> > > Is there anything I can do more efficiently, both
> > from
> > > a general Perl and a specific CGI::Application
> > > perspective? For instance, should @crudButtons be
> > > replaced by a (scalar) reference to an anonymous
> > list?
> > > And/or, will it save overhead to pass the $cgi
> > > reference to $self->query() as a param to be used
> > by
> > > the run modes?
> > >
> > > Etcetera. Thanks in advance. Eventually I may
> > > migrate some of the above to cgiapp_init, and
> > perhaps
> > > in the long term work on something I might call
> > > CGI::Application::CRUD, where CRUD is not only a
> > > meaningful acronym, but also a way of managing
> > > expectations ;)
>
> Here's my latest stab at it with comments. Added an
> abort mode and changed some identifiers, including
> capitalizing run modes to avoid confusion with
> built-in Perl funcs. Still my main CGI::Application
> question is, does it save any overhead to pass $cgi as
> a $self->param? Could be an issue, because though I'm
> starting on a Windows based intranet and am using
> ActiveState's PerlISAPI, this could be ported to a
> virtually hosted Linux machine where it might have to
> run as CGI rather than under mod_perl.
>
> Thanks!!
>
> #
> sub setup
> {
> my $self = shift;
> my $cgi = $self->query();
>
> #Permissible application states passed via html
> submit button name parameter
> my @crud = qw(Create Read Update Delete);
>
> my $defaultMode = 'Create';
> my $crudMode = $defaultMode unless $cgi->param();
>
> my $crudCall = sub {return $crudMode}; #For callback
> by mode_param method
>
> #Determine mode based on existence of like-named cgi
> parameter, or abort
> $crudMode = GetSubmittedCrud(\@crud, $cgi->Vars) if
> $cgi->param();
> $crudMode = 'Abort' unless $crudMode;
>
> #Since mode_param can change use callback instead of
> hardcoding
> $self->mode_param($crudCall);
>
> $self->param('cgi' => $cgi);
> $self->param('buttons' => \@crud);
> $self->param('crudMode' => $crudMode);
>
> #Data structure containing database, hidden field
> and template information
> $self->param('appDefs' => AutoDefine($cgi));
>
> #One run mode per @crud entry, plus an abort mode
> foreach my $button (@crud)
> {
> $self->run_modes($button => \&$button);
> }
> $self->run_modes('Abort' => \&Abort);
>
> }
>
> #
>
> =====
> George M. Jempty
> Database Admin/Intranet Architect
> Regional West Medical Center
> Scottsbluff, Nebraska
> [EMAIL PROTECTED][EMAIL PROTECTED]
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
http://mark.stosberg.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
