I'm doing some analysis on the scheme proposed by Karl for a new way to handle
conditions raised by 'abort_page', 

My proposal is to add 2 new configuration script and extend the globals with
2 new status variables:

 - AbortScript: script that gets run if abort_page is called by the content
generator or by AfterScript. 
 
 - ForceAfterScript (or FinalAfterScript or whatever): it's run anyway
regardless the completion code of the script that ran before in the request
process

 - Command abort_page will have an internal status flag 'aborting' to be set
in the module globals. This flag is set to 0 at the very beginning of the
request processing (Rivet_SendContent). 'abort_page' tests this flag, if 0 it
gets set as 1 and the command returns TCL_ERROR setting the usual error info
that are trapped in Rivet_ExecuteAndCheck. 

Any subsequent call to the command will return TCL_OK disabling its effects
within ForceAfterScript (just making sure that it cannot be interrupted in
this way).

- 'abort_page' will accept an argument to be later retrived with a new
command 'abort_condition'. AbortScript may check this condition variable to
branch into different blocks of code.

Basically, the code in Rivet_ExecuteAndCheck where the abort condition is 
checked

if (strcmp (Tcl_GetString (errorCodeElementObj), "RIVET") == 0) {
 ...

}

should test the definition of a new conf variable rivet_abort_script and
execute it if defined. The whole function has to also check for the new conf
variable rivet_force_script and run it anyway before printing the headers and
flushing the channel.

thoughts?

-- Massimo


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Reply via email to