Hi Everyone...

We just noticed that AfterScript gets tagged onto the text of the webpage such 
that, if something in the page does an abort_page, there's no Rivet config 
script that's going to get a crack at the interpreter before it sits waiting 
for the next request to invoke it.

How abort_page works is its invokes a Tcl error with an errorCode of RIVET 
ABORTPAGE.  If the mod_rivet.c code that invokes Tcl_EvalObjEx then it bypasses 
the error handler and continues (Rivet_ExecuteAndCheck) with the flush and 
release.

It's also valid for the AfterScript itself to invoke abort_page, IMO.  We do 
that.

One possibility would be to invoke the AfterScript using Tcl_Eval in the 
abort_page path.  But that would break the AfterScript being able to invoke 
abort_page.  Also it would change the behavior every page that does an 
abort_page in a possibly bad way.  

No, I think AfterScript should stay the way it is.

If people agree that it should be possible to specify code in the 
configuration, an additional after script, that gets executed whether the page 
aborted or not.  Maybe it would be AbortScript (that's pretty simple).  But the 
code in the page shouldn't be able to do an explicit return and bypass this 
script either.  (I think a bare return in the page will bypass the 
AfterScript).  So it's a second After script, the after script of last resorts 
that's always guaranteed to execute whereas AfterScript is not.  
ForceAfterScript?  AlwaysAfterScript?



---------------------------------------------------------------------
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