Jesse, > > 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". >
Point taken. > > Are TWO state machines enough? Will someone ask for a THIRD > or FOURTH state > machine some day? Where do we draw the line? > Well, certainly for a general FSM implementation it would be important to allow an "large" number of look-up keys. However, since this is a CGI-App FSM, two works quite nicely. It seems to me that each CGI script has two distinct tasks: 1) do whatever "action" is required (if any) to process the current page, and 2) generate the next page. > > 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. > So noted. And in fact, I currently am using home grown code based on CGI::App for my "action" state machine. However, it amounts to a large amount of what is essentially duplicate code. Hence my desire to leverage off CGI-App, if possible. > > This hook should allow you to make additional FSMs which do > whatever you > want. Does this accommodate your desired functionality? > As an aside, let me note at this point that the title of this thread is very misleading. This title came from someone who, like me, was trying to call run() twice - once for an action and once for the output. He was using the CGI_APP_RETURN_ONLY environment variable to suppress the print() during the action phase, but he was still stuck two sets of headers. Not to mention the fact that this environment variable claimed to be for "serious debug mode only"! Bottom line - we don't really want a hook to "grab" the output without headers. :-) Drum roll please: What we really want is a hook to suppress the entire print operation (headers, body, and the print itself) when the run-mode is an "action" type of run-mode. My proposal in a previous post was to split run() into two (possibly private) new subroutines. One that invoked the run-mode (everything before the preoutput call) and another that built the headers and did the print (everything after the preoutput call). Then the CGI::App run() would call both subroutines in order and behave exactly as it does now, but anyone could overload run() to implement some decision making about whether or not 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. What do either of these proposals do for you? Tim, you wanna jump in here? Thanks for spending so much time on this with me, Elizabeth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
