> From: Jesse Erlbaum <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Fri, 4 Jan 2002 13:51:45 -0500
> Subject: RE: [cgiapp] Please critique my setup
> method
>
> Hi George --
>
> > $self->param('buttons' => ['Create', 'Read',
> > 'Update', 'Delete']);
> > $self->runModePerButton();
>
> My $0.2:
>
> Do you find it at all suspicious that you have
> replaced the whole concept of
> run modes with these "buttons"? Effectively, that
> it what you have done.
> Instead of specifying run_modes(), you now have
> buttons from which run-modes
> are derived. Instead of looking at a run-mode
> parameter, you look at the
> button name to figure out what to do next.
>From the time I first started tinkering with CGI, just
3 years ago, I always thought that submit buttons were
greatly under-utilized in maintaining state. Between
this, and the recent discussion on this group about
'finite state machines', I thought I could use submit
buttons to that end, within the framework of
CGI::Application.
> The best metric of how close you are to the spirit
> of CGI::Application's
> desired mode of behavior is the size of your setup()
> method. A small
> setup() method indicates that you are working with
> CGI::Application. A
> large setup() method suggests that you are working
> against it.
My setup is only 15 lines, excluding comments, and 5
of those are calls to $self->param(). I thought this
was pretty compact. Perhaps I abstract out some of
the excess using cgiapp_init()?
> Everything else would be handled by setting the form
> parameter 'rm' to the
> appropriate value. That would be done in my
> run-mode methods. I would not
> try to connect the text on a submit button to the
> run-mode, when creating a
> "hidden" form field containing the run-mode I want
> is so trivial:
>
> <form>
> <input type="hidden" name="rm" value="create">
> <input type="button" value="Create a new Whatever">
> </form>
Unfortunately this could never work for the system I
am envisioning, because, even if you are in the middle
of a 'create' of a new record, the back button is a
'read' of the previous page's data.
> My suggestion to you is to take a step back and
> evaluate whether or not
> CGI::Application is helping you. What is it you are
> trying to achieve by
> using CGI::Application? Are you using it for what
> it is good for
> (specifically: Managing run-modes and providing a
> common architecture), or
> are you bending it into a pretzel which only makes
> your job more difficult
> and eliminates any benefit you would have otherwise
> gained from using
> CGI::Application?
>
> Obviously, I do not want to discourage you from
> using CGI::Application. I
> just want to make sure it is making your job easier
> -- not harder.
I still believe I am getting great benefit from
CGI::Application. I was going to use CGI.pm and
HTML::Template anyway, so it gives me a wrapper around
the two of them: scaffolding so to speak. This is my
first project on this scale so its nice to have a firm
foundation to fall back on, as well as the support of
this email group (which I hope I am not abusing).
CGI::Application gives me plenty of robust hooks, and
this gives me the freedom to create my own design.
Otherwise I might be tempted to modify somebody else's
library, such as DB_Browser as suggested by Mark
Stosberg. Though, in the long run, what I have in
mind might just be a finite state machine for
database/web interaction that is somewhere between
these two libraries.
Thanks for everybody's consideration, patience, and understanding.
=====
George M. Jempty
Database Admin/Intranet Architect
Regional West Medical Center
Scottsbluff, Nebraska
[EMAIL PROTECTED][EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
