Hi George --
> I don't know about Tim and Elizabeth (I get the digest
> so don't know if they've responded yet), but this
> works for me!! I've got a multipage database front
> end that needs to handle both inserts on new records,
> and updates on existing records. I'm using a naming
> convention for my templates, Page1.html, Page2.html,
> and then pass the page number as a hidden field named
> 'origin'. I don't want a seperate run mode for each
> page though, because they all basically do the same
> thing: insert or update a database record.
Figuring out where to use run-modes is a complicated issue. (I hope to
write something soon which will help application designers use
CGI-Application.) Besides "ubermode" what other run-modes will you have in
your application?
If you find that you have no other run-modes, perhaps you shouldn't be using
CGI-Application for this web app at all! CGI-App's greatest benefit (IMHO)
is managing an application with multiple "states" (a.k.a., "run-modes"). If
you're not using that functionality, what is CGI-App doing for you?
If CGI-app is beneficial to you in spite of NOT utilizing run-modes, I would
be interested to hear why. It is quite possible that there are other
benefits to using CGI-App to which I've not really given sufficient
consideration.
> Which database action is performed is determined by
> the NAME of the submit button, and the buttons are
> generated by a subroutine that knows whether to
> display '< Back', and/or 'Next >' based on the last
> consecutive template number, using the same naming
> convention indicated above.
Is there any possibility that you might want to change the name of those
buttons some day? In the early pre-Javascript days, I had to do similar
things if I wanted to have an image as a button. It was a huge PITA (Pain
In The Ass), 'cuz the HTML implementation was tightly coupled to the
application functionality. Since Javascript has matured, I have moved to
having buttons like this:
<input type="button" value="Next" onClick="javascript:go_next()">
The go_next() Javascript function sets the run-mode form parameter and
submits the form. This way I can easily change the on-screen text without
having to change code. In a nutshell, better separation between design and
functionality.
> So, your idea of an ubermode is just what I'm looking
> for, then your suggested private 'action' method can
> take care of all this other processing 'under the
> hood', and/or implement special functionality, for
> instance, for page 1, where I need to get an id from
> the database to pass from page to page.
If your functionality is really so homogenous that all screens can be
handled by a single function, great! However, beware of re-inventing
CGI-Application in your action() method. Unless your functions are 100%
homogenous, I am virtually certain that your action() method will very
quickly start looking like a big switch:
sub action {
my $self = shift;
my $output;
if ( somecase() ){
$output = do_something();
} elsif ( someothercase() ) {
$output = do_something_else();
} elsif ( yetanothercase() ) {
$output = do_some_different_thing();
} else {
$output = do_something_if_nothing_else_fits();
}
return $output;
}
My advice to you is that if you start implementing something which looks
like this, take a step back and consider a more traditional CGI-App
approach.
TTYL,
-Jesse-
----
Jesse Erlbaum, CTO
Vanguard Media
212.242.5317 x115
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
