> -----Original Message-----
> From: George Jempty [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 20, 2001 8:37 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [cgiapp] Grab output of a run mode without headers --
> possible solution?
>
>
> > Hi Tim & Elizabeth --
> >
> > Regarding this (very interesting!) conversation, I
> > think I just had a
> > "moment of clarity" about which I'm interested in
> > your feedback.
> >
> >
> > A while back, Elizabeth wrote this:
> >
> > > My original idea was for the base class to look
> > > something like this:
> > >
> > > subroutine run {
> > > my $rm_output = action();
> > > return output( $rm_output );
> > > }
> > >
> > > where action() was a (private?) subroutine that
> > invoked the correct
> > run_mode
> > > call and output() formatted and printed the
> > output. In this way the
> > current
> > > implementation of run is not altered in the least
> > - just modularized a
> > > little.
> >
> >
> > Instead of putting this in the run() method, what if
> > you created a single
> > run-mode which ran your entire application? Call it
> > "ubermode":
> >
> >
> > sub setup {
> > my $self = shift;
> > $self->run_modes(
> > 'ubermode' => \&ubermode
> > );
> > $self->start_mode('ubermode');
> > }
> >
> > sub ubermode {
> > my $self = shift;
> > my $rm_output = $self->action();
> > return $self->output( $rm_output );
> > }
> >
> > ## Private methods ##
> > sub action {
> > my $self = shift;
> > my $action_output;
> > # invoke the correct run_mode call
> > return $action_output;
> > }
> >
> > sub output {
> > my $self = shift;
> > my $output_output;
> > # format and print the output
> > return $output_output;
> > }
> >
> >
> >
> > Would this not do exactly what you want?
> >
> > -Jesse-
>
Jesse,
Did you write this sometime back - I don't remember seeing it specifically?
In any case, I would like to respond. I am not entirely sure I am correct,
but I think this is the opposite of what I want. I want twice as many
run-modes as I have now, not just one!
"CGI-App's greatest benefit (IMHO) is managing an application with multiple
"states" (a.k.a., "run-modes")." - Jesse
I couldn't agree more! In fact, what I want is two different state
machines - one to process the current page (the action) and one to generate
the new page (the output). I want each state machine to have it's own
run-mode variable so that, if need be, they could actually be cranked
independently. I find that which page to display next regularly has very
little to do with the current page.
Just so you know, I have written several large state machine driven
applications. One was a parser that was about a 10 x 10 decision tree. The
other was a maze router that was a binary state machine with about 200
states and a true/false branch condition. CGI::Application, as it is
currently implemented is a unary state machine. All conditions must be
tested within the run-mode. What I am finding is that I am asking the same
set of conditionals over and over in each run-mode. So, since
CGI::Application is so good at managing state transitions, why not put it to
work on this decision also?
To put it another way, is CGI::Application a program that generates HTML or
is it a program that implements a state machine? I think it is both! IMHO,
a great deal can be gained by exposing the interface to each of these
components as separate entities. Keep run() to maintain backward
compatibility, but separate run() into the piece that invokes the run-mode
and the piece that generates the output. Then customization could easily be
done in an overloded run(). Or, you could be even more daring and another
"table" that is the action-mode, which duplicates the run-mode except for
the printing part.
Thanks,
Elizabeth
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
