Massimo Manghi wrorte:

>P.S. Please, in order to amend our documentation would you tell us what
>     is the page of the manual you found misleading?

Hi Massimo, thanks for your comments.

I think these pages need a rewrite:

http://tcl.apache.org/rivet/manual2.2/request.html Tcl Namespaces in
Rivet and the *::request* Namespace

"With the sole exception of .rvt templates, Rivet runs pure Tcl scripts
at the global namespace. That means that every variable or procedure
created in Tcl scripts resides by default in the "::" namespace (just
like in traditional Tcl scripting) and they are persistent across
different requests until explicitly unset or until the interpreter is
deleted. You can create your own application namespaces to store data
but it is important to remember that subsequent requests will in general
be served by different child processes. Your application can rely on the
fact that certain application data will be in the interpreter, but you
shouldn't assume the state of a transaction spanning several pages can
be stored in this way and be safely kept available to a specific
client."

This should say: "because of the Apache architecture <blah><blah>, it
is not possible to attain global variable persistence across requests
in any case. Because of that, really there is nothing "to rely on". Data
is is not predictably accessible is simply not accessible.

And: 
http://tcl.apache.org/rivet/manual2.2/internals.html#idp99252480
"The solution we have created is to create a proc *::request::global*
that takes the place of the *global* command in Rivet templates. If you
really need a true global variable, use either *::global* or add the ::
namespace qualifier to variables you wish to make global."

This doesn't make sense either. As we discusses, there is no way to
create "truly global
variables" at basic TCL level. 

Cheers, Paolo.
<i>Always striving to honor my word and commitments</i>


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to