> From: Jesse Erlbaum <[EMAIL PROTECTED]>
> 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.
Thanks for the input....I knew this too would be an
issue I might have to consider
> 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-
I've been thinking about this for the last day and a
half. I'd been working on this app seperate from
CGI::Application for a couple of weeks, then the
"ubermode" idea got me considering it again. However,
I think I will take a different tack, though still
with CGI::Application.
I foresee 4 runs modes: delete, insert, select,
update, or, if you will: CRUD (create, read, update,
delete). As mentioned I will determine this from the
name of the submit button(s), which will have been
created with a subroutine.
Now my idea is this: in setup I will first get ALL the
pertinent state data, perhaps as follows:
my $appDefs = $self->autodefine(); #custom private
method
The name of the submit button will be amongst all the
data that $appDefs will point to (autodefine will
return an anonymous hash reference). Then, based on
reading the source code for CGI::Application v2.1, I
will pass a subroutine reference to
$self->mode_param(). The subroutine will return the
name of the submit button: delete, insert, select, or
update, and there will be a corresponding run mode for
each of these possible actions (by the way, there will
be a number of commonalities between these run modes
that can be further modularized, e.g. select and
update will return a pre-populated template form, as
opposed to one that only contains defaults or is
empty, such as for an insert).
I was _extremely_ happy to see that I could have
mode_param() execute a callback. Has anybody else
utilized this functionality yet, to your knowledge?
And as ever, thanks for your response(s).
=====
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]
