There is some more we can do. The template parser needs to know whether
the template is 'top-level' or not. If it's a URL referenced template
(toplevel=true) encloses the parsed script in a namespace request { }
statement. With the new model we could put that namespace evaluation in
::Rivet::url_handler. This would make the coupling of the Rivet parser
with other components a bit more relaxed, which is good design practice.
That would make possible to remove the hard coded ::request namespace
creation and move it in either ::Rivet::url_handler or request_handling
(the former probably a better choice because that would make the
::request namespace an almost exclusive responsibility of that procedure)
The problem is that this wouldn't work with the traditional mod_rivet
core, but I think I could manage the situation, even if we decided to
maintain that code by moving that 'namespace request {}' out of the
rivet parser: top level templates are evaluated in a specific and point
like condition
-- Massimo
On 11/12/2016 07:23 PM, Damon Courtney wrote:
The first thing I see is that we need to set some of the defaults. We
have some duplicating going on that can be cleaned up.
Examples:
ErrorScript should default to ::Rivet::handle_error
AfterEveryScript should default to ::Rivet::cleanup_request
Rather than looking for those scripts and then using the ::Rivet
defaults when we don’t find out, we should just default those values
in the module, and then we don’t have to do any of that dance.
The only breaking change is that ::Rivet::cleanup_request is
currently called on every request even if AfterEverScript has been
specified. This would call for only one, which breaks backward
compatibility, but I don’t think in a really significant way. Most
everyone should be using AfterEveryScript instead of the older way of
redefining procs anyway.
It looks like we’re going to call this Rivet 3.0, so now is the time
to reevaluate some old decisions and make changes. I don’t think this
is a big one or that controversial. I could be shouted down if
someone cared enough though. :)
D
On Nov 12, 2016, at 11:52 AM, Massimo Manghi <man...@biol.unipr.it>
wrote:
now the code its ready. You need to recreate an init.tcl script by
running ./configure with the appropriate arguments. The key switch
is
./configure ... --with-rivet-core=mod_rivet_ng
the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is
comprised between the lines
######## mod_rivet_ng specific ++++++++
.....
######## mod_rivet_ng specific --------
everything else is untouched therefore it should be compatible also
with the traditional default core module
I'm looking forward to read you comments
cheers
-- Massimo
On 11/12/2016 06:34 PM, Damon Courtney wrote:
Sure thing.
--
--
Dipartimento di Neuroscienze
Unità Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
