On Jun 25, 11:47 pm, Voltron <nhy
...@googlemail.com> wrote:
> I need to have my session initialized very early so that I can pass
> them to the global environment of the templating system I am using. I
> read somewhere about these solutions:
How early is early? Sessions are currently initialized at the
'before_request_body' hook. See the diagram at
http://www.cherrypy.org/wiki/RequestObject.
If your templating system runs at the 'on_start_resource' hook, the
best approach would be to either move it to the 'before_request_body'
hook (at, say, priority 60 so it runs after the session tool), or move
the session tool to run at the 'on_start_resource' hook, with a low
priority number so it runs before your templating setup.
> storage_class = storage_type.title() + 'Session'
> storage_class = globals()[storage_class]
> if not hasattr(cherrypy, "session"):
> if hasattr(storage_class, "setup"):
> storage_class.setup(**kwargs)
> My questions are:
> 1. Some backends do not have the "setup()" function, how should these
> be handled then?
That's what the 'hasattr' check is for. Nothing needs to be done if a
backend has no such method.
> 2. If the backend is initialized also by turning "tools.sessions.on"
> in the global configuration, and separately again when triggering an
> early initialization, would that lead to problems? Asynchronous
> sessions?
The code you pasted above is from cherrypy.lib.sessions.init(), which
is called when you turn tools.sessions.on. If you're duplicating the
functionality of init() somewhere else, you probably don't want init()
to run again. So you'd usually turn the tool off and manually add the
hooks it does. Fortunately, *if* you duplicate *all* of sessions.init,
you'll see there's a guard in there against running twice, so in the
case of the session tool you can work around this. But don't do that;
instead, use the priority system to run your tools in the desired
order.
Robert Brewer
fuman...@aminus.org
|
