Hi Elizabeth --
Thanks for your message. It has clarified a number of issues for me.
> ....is CGI::Application a program that generates HTML or
> is it a program that implements a state machine? I think it
> is both!
You suggested a question in an earlier message which was similar:
"Is CGI-App a framework which uses a FSM (Finite State Machine), or a FSM
engine which implements a CGI application framework?"
In my mind, CGI-App is an application framework. It happens to make use of
a FSM, because a FSM is the appropriate structure (IMHO) for multi-screen
web applications. CGI-App *is not* a general FSM "engine". If it was, it
would probably be called "FSM::CGIApp".
> 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.
Are TWO state machines enough? Will someone ask for a THIRD or FOURTH state
machine some day? Where do we draw the line?
CGI-Application was designed to handle the most-common denominator. No
matter who you are or what you're writing, your web application will have
multiple screens. That is the common denominator. Specific programmers and
specific projects may have specific requirements, which is why the
sub-classable architecture has proven useful.
Something to think about regarding web application "State Machines": Is not
EVERY FORM INPUT a state variable? I have set aside a single variable to
track a single run-time property: The "run-mode". Every application has
more than just a run-mode variable state. (If they didn't, we'd all use
static HTML!) It is the job of your run-modes to interpret all the other
form inputs besides run-mode. If you choose to use a FSM to do so, that's
up to you. Does it have to be the same FSM which CGI-App uses for handling
run-modes? Of course not.
That said, I hear what you're saying, and I think I can accommodate you and
Tim, without making CGI::Application any more complicated for most of the
users who just want to use it for run-mode management.
We currently have a hook, cgiapp_init(), which allows developers to
sub-class CGI-App and implement inherited behaviors during construction,
before a request is actually handled. I propose to add another hook,
cgiapp_preoutput(), which is called after the run-mode returns its output,
but before the output is send to the browser. The cgiapp_preoutput() method
will be send a scalarref containing the $output, so that it can be evaluated
and/or modified.
The CGI-App run() method will be modified to look something like this:
----START---->
# Process run mode!
my $body;
if (ref($rmeth) eq 'CODE') {
if ($autoload_mode) {
$body = $rmeth->($self, $rm);
} else {
$body = $rmeth->($self);
}
} else {
my $meth_call = '$self->' . $rmeth;
$meth_call .= '($rm)' if ($autoload_mode);
$body = eval($meth_call);
die ("Error executing run mode '$rm'. Eval of code
'$meth_call' resulted in error: " . $@) if ($@);
}
# Call Pre-output hook:
$self->cgiapp_preoutput(\$body);
# Set up HTTP headers
my $headers = $self->_send_headers();
<----END----
A no-op implementation of cgiapp_preoutput() will be included in CGI-App so
that nobody will have to change their existing code to accommodate this new
hook.
This hook should allow you to make additional FSMs which do whatever you
want. Does this accommodate your desired functionality?
Warmest regards,
-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]
