Hi Elizabeth --
>to generate the output. Alternatively, the preoutput hook could be
>where
>this decision making code exists. You would just need to have it return
>a
>bool that indicates whether run() should return *before* generating any
>headers and actual output.
The placement of the cgiapp_preoutput() hook in the run-method would provide
a perfect opportunity for you to do something before headers or output are
sent to the web browser client.
In essence, this is what the application flow would look like:
my $body = <run mode output>;
$self->cgiapp_preoutput(\$body);
my $output = <headers> . $body;
print STDOUT $output;
As you can see, at the point cgiapp_preoutput() is called you would have the
power to completely change the content of $body to whatever you want.
Because this is an instance method, you also have total access to the $query
state, so you can read any form variable you like.
I imagine your cgiapp_preoutput() method might look like this:
sub cgiapp_preoutput {
my $self = shift;
my $body_ref = shift;
my $q = $self->query();
my $output_runmode = $q->param('output_runmode');
my $output_runmodes = {
'output_one' => \&output_one,
'output_two' => \&output_two,
'output_three' => \&output_three,
};
${$body_ref} = $self->($output_runmodes{$output_runmode});
}
(I've not actually run this code. It should be expected that I've missed a
bracket somewhere!)
Personally, I wouldn't use this system -- I'm totally happy having my
run-modes handle the transition decisions w/o another decision layer. I
might use the cgiapp_preoutput() method to add a footer, or something:
sub cgiapp_preoutput {
my $self = shift;
my $body_ref = shift;
${$body_ref} .= "<b>Jesse wuz here!</b><br>\n";
}
(Maybe this will be the default cgiapp_preoutput()? Hehe..)
TTYL,
-Jesse-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
