Shane Hathaway wrote:
Hi all,
I'm trying to get a handle on Zope 3. I plan to take a bunch of Zope 3
modules and combine them in a new way. The goal is to create for myself
a comfortable working environment that lets me run simple code in a
small mod_wsgi environment with easy reloading and no ZODB initially.
To achieve this, I need to understand what's going on in the Zope 3 code
base. While the code itself is easy to understand, there are many
comments in the code that suggest changes are coming soon. Please help
me figure out what is meant by these comments.
The first cryptic comment comes from zope.component. The _api module
starts with this gem:
# SiteManager API. This needs to get deprecated eventually.
I think this meant to say that the word "Site Manager" has been
deprecated. Nowadays we just say component registry. In theory. I think
we just found that renaming things isn't worth all the trouble.
But... um... everything in the module uses getSiteManager(). The whole
component foundation is built on it. When is it going to be replaced?
With what? By whom?
I think the comment can go. It's the opposite of useful right now.
I'm assuming for the moment that the comment is a lie, and that
getSiteManager() is not going away, since otherwise I have no foundation
to build upon.
Yup.
I think I want to use a threading.local as my site manager. That way, I
can use a different configuration for each WSGI app even if several apps
run in different threads of a single Python interpreter. It looks like
the zope.app.component.hooks module does something like what I want, but
that module is complicated and lacks comments in the places that matter,
so I'm not quite sure what it accomplishes. I'll add comments to that
module if anyone can explain it fully.
zope.component.getSiteManager() is a "hooked" function (using
zope.hookable). That means it can be replaced by some other
implementation. zope.app.component.hooks makes use of that. It replaces
zope.component.getSiteManager() with an implementation that looks up a
thread local variable (SiteInfo). This replacement is done in the
setHooks() function which is called some time during Zope startup.
That led me to the zope.thread module, which is apparently deprecated
already, yet zope.app.component still depends on it. Is that an
hysterical accident?
As said previously, zope.thread.local is just a wrapper around Python's
threading.local module (which was contributed by Jim based on
zope.thread.local).
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
