I'm trying to envision what 'ForceAfterScript' would be meant for and
the only purpose I can imagine is to catch resources that may have been
left open or in a inconsistent state (e.g. a transaction rollback).
After all it's like the last catch of an exception mechanism where
abort_page plays the role of a 'throw'. If my vision is correct we may
also extend the mechanism and introduce a state variable which might
work as an 'exception object' to be used to hand down to
'ForceAfterScript' (perhaps to be named 'RequestCatchScript') some other
info. Something like
abort_page <error_code>
that might be fetched later on through a new command 'abort_condition'
(a pure state variable could be enough but I don't like it because it
can be manipulated...)
-- Massimo
P.S. I have reasons to believe there are problems with the email
delivery from rivet-dev to my mailbox. At the moment please CC your
answer to my personal address. Thanks.
On 02/06/2011 09:01 PM, Karl Lehenbauer wrote:
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: [email protected]
For additional commands, e-mail: [email protected]
