This looks pretty good. We'll give it a try. I was thinking that ForceAfterScript might be called AfterEveryScript. I just like the sound of it, but no biggie.
I was also thinking possibly instead of having an AbortScript just have a flag that can be queried to see if the page got here by abort_page or what, but this solves the problem and there's already code written. I hadn't thought about the abort-within-an-abort scenario. I think that's pretty smart. On Feb 11, 2011, at 4:50 PM, Massimo Manghi wrote: > I committed in the branch rivet/branches/neh (new exception handling) the code > that introduces 2 new conf scripts: > > - "AbortScript": the script is invoked after an 'abort_page' commands has > been called and content generation interrupted > > - "ForceAfterScript": the script is run anyway after the page content > generation has ended (also after an 'abort_page') > > 'abort_page' now accepts an optional arbitrary parameter to be stored > internally in the module globals. The value of this parameter can be retrieved > through the command 'abort_code'. > > 'abort_page' is effective only on the first call during a request processing: > on all the subsequent calls the command returns TCL_OK and has no effect > whatsoever. This is needed to prevent AbortScript and ForceAfterScript from > returning with a "RIVET" error code that cannot be handled in the same way > it's done during content generation. > > Since ForceAfterScript is to be run anyway, the programmer may need to know if > execution happens after page generation was interrupted because of an > 'abort_page' call. Hence the command 'abort_page' supports now the form > > abort_page -aborting > > that returns 1 if the execution happens after content generation was > interrupted. I know some of you are frowning at this form. Take it a > experimental: I'm open to change it. > > It's not too clear to me whether ForceAfterScript should run if ErrorScript > has run....My opinion is that ForceAfterScript could by design be there to > catch resources left in a inconsistent state and it's sensible to run it > anyway. > > These features are not yet documented. They will be as soon as the code will > meet approval of those who will be bothered testing it. > > -- Massimo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org > For additional commands, e-mail: rivet-dev-h...@tcl.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
