OK, sure, I'll start with some plain English up here,
which will help me come up with appropriate code
comments in the long run. Sorry for not including
this to begin with, it is a sort of continuation of
previous posts of mine.
This is a database front end. There is a run mode for
each of the possible database modes: create, read,
update, delete. This mode will be passed as the name
of the various navigation/submit buttons; a general
method for generating these buttons will be called by
each run mode.
The GetSubmitNames subroutine (not shown), determines
which crud/data mode from the $cgi/$self->query()
object. If it is the very first invocation of the
application of the program, the default mode is
'create', so the user can start by entering a new
record.
As an example, however, the mode might change from
page to page. For instance, the user may have started
entering a new record ('create' mode), but they could
hit the '< BACK' button, which would be named 'read',
so as to initiate reading the prior page's data.
(Another example would be hitting 'FINISH >>' will, if
the submitted data validates, always return to a fresh
page 1 in insert mode.)
Since the mode can change, I cannot be assured of the
existence of a statically defined mode_param.
Instead, I use the mode_param method's callback
functionality by passing it an anonymous subroutine,
to be assured the proper run_mode is initiated.
$selfState will be a reference to a data structure
(hash of hashes?), in which database and template
information will be specified. For instance, the
primary data field and/or the path where templates
reside.
Additionally, it will hold information passed via
hidden fields, such as the page number, and the id
number for the current record (which will be based on
the primary data field). By not including this sort
of thing in my first post I was engaging in
"information hiding", but I see how this could be
helpful for critiquing my code.
This might be more than necessary, it gets more into
the implementation of the run modes, but I still think
it is cool. I have ascertained many commonalities
between the first 3 modes, create, read and update.
For instance, create and update both have a validation
piece, which, by the way, if successful, increments
the page number.
On the other hand, 'create' only reads certain default
values from the database in order to assemble its
output. In this instance, 'update' acts similarly to
'read', it reads ALL necessary data, based on the
unique record id, in assembling its output.
I have gone into detail a couple of previous times
about my naming convention for HTML form fields, so
they can be readily mapped to the appropriate data
tables; an example of such a name attribute might be:
'DB_patient_lastName'.
Hope this helps, and thanks again: this is my first
design on this scale, and this group has been a
tremendous resource.
George Jempty
--- 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 ;)
> >
> > =====
> > 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]
>
> --
__________________________________________________
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]