OK, it's implemented and committed, as proposed. If you look at
mod_rivet.c, you'll see if it gets TCL_ERROR, it susses out the
errorCode and figures out if it's RIVET/ABORTPAGE, etc.
I was thinking maybe to add an option to prevent any
ChildAfterScripts from executing, like abort_page -noafterscripts.
Also "die" takes a message, abort_page currently does it.
We really need to upgrade the docs -- php has the ability to add
comments to pages, I have rivet code to support that (quite cool),
but it relies on a database and stuff. Don't know if we have that
kind of ability to build stuff on tcl.apache.org.
Karl
On Aug 1, 2005, at 9:39 AM, Damon Courtney wrote:
I think it's a great idea! abort_page has always kinda' been
crap.
It never really did what I wanted it to do, which is what you're
describing here. It was always a pain to have to work around it. In
my earlier days, I would actually call 'exit' to get the behavior I
wanted not knowing that it was actually causing the interp to exit.
0-]
I appreciate the solution and the effort.
Damon
Greeetings...
I think abort_page is pretty broken. It aborts the connection, which
can confuse browsers that are doing a keep-alive. Worse, it doesn't
really abort the page, it just causes the same result as a return,
meaning that if abort_page is called from a proc, for example, that
proc returns, but the proc that called it continues executing.
It needs to work more like "exit", but without destroying the
interpreter or exiting the Apache process, of course.
I propose that we change abort_page to work like this:
When abort_page is called, it generates an error with an errorCode of
something like {RIVET ABORTPAGE "Page aborted by abort_page
directive"}
The top-level C code that calls Tcl_EvalObj to execute the .rvt page
(or parsed page, etc) currently, if TCL_ERROR is received, executes
an error handler if it's defined and, if not, or if the handler gets
an error, does some error output on its own. I propose that this
code be modified to recognize the RIVET ABORTPAGE errorCode and, when
it's that, not do any error processing, neither calling the error
handler nor outputting anything on its own.
One slight change this would introduce in the behavior is that if a
catch wrapped the code that executed abort_page, that catch would
catch it -- but this is also a feature, because it gives a project
the ability to catch abort_page and do any special cleanup or
handling they want to do. It could break some code, though, that
does a catch and is indiscriminate in looking at what it got.
However the way abort_page works right now is quite broken, as much
more Tcl code can continue to be executed, it just doesn't get
output, and it generates an empty page sometimes, when it shouldn't.
This is a very simple change -- only a handful of lines of code in
two places. I'm willing to do it, if nobody thinks this is a
horrible idea or comes up with something better.
Regards,
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
