[Zope-dev] Deciphering Zope Comments
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. 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'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. 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. 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? Shane ___ 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 )
Re: [Zope-dev] Deciphering Zope Comments
Previously Shane Hathaway wrote: 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. You can also use a paste.registry StackedObjectProxy to provide access to a thread local site manager via the standard wsgi environ. That certainly fits well with the WSGI model and other frameworks such as Pylons and Turbogears use it. I'm not sure if Zope3 exposes that properly though. Admitedly paste.registry is not the best documented code either; some cleanup there is still useful but the ideal model has not been worked out yet. 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? I only learned yesterday that zope.thread is now basically just a wrapper around python 2.4's threading module so you can use that directly. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] Deciphering Zope Comments
Wichert Akkerman wrote: Previously Shane Hathaway wrote: 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. You can also use a paste.registry StackedObjectProxy to provide access to a thread local site manager via the standard wsgi environ. That certainly fits well with the WSGI model and other frameworks such as Pylons and Turbogears use it. I'm not sure if Zope3 exposes that properly though. Admitedly paste.registry is not the best documented code either; some cleanup there is still useful but the ideal model has not been worked out yet. Thanks for the pointer. I'm not quite sure how StackedObjectProxy might fit in, but if it turns out I need it, at least now I don't have to rewrite it. 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? I only learned yesterday that zope.thread is now basically just a wrapper around python 2.4's threading module so you can use that directly. Fred Drake also confirmed that nothing needs to use zope.thread anymore. I plan to clean it up. Shane ___ 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 )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Tue Jun 3 11:00:00 2008 UTC to Wed Jun 4 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Jun 3 20:54:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009650.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:55:46 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009651.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:57:17 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009652.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:58:47 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009653.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 21:00:17 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009654.html ___ 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 )
Re: [Zope-dev] Deciphering Zope Comments
On Tuesday 03 June 2008, Shane Hathaway wrote: # SiteManager API. This needs to get deprecated eventually. 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? This is a result of the big zope component cleanup. I forgot the details. Jim would be the best person to answer this. If he does not know, we should just remove the comment. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
[Zope-dev] Re: Deciphering Zope Comments
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 )
[Zope-dev] SQLAlchemy (zope.sqlalchemy) integration
Hi, Regarding to the discussion some days ago with the SQLAlchemy Zope3 integration, I still have problems with retrieving the session. I currently use a utility for the engine, which seems to work well. However, for retrieving the session, I tried to use the following pattern (many thanks to Michael Bayer, btw.): database module --- SASession = scoped_session(sessionmaker( transactional = True, autoflush = True, extension = ZopeTransactionExtension())) def getSASession(): SASession.remove() engine = getUtility(ISAEngineUtility).getEngine() s = SASession() s.bind = engine return s In my application, I then use getSASession() to retrieve my session. However, what I think is not that beautiful is the s.bind = engine part. Are there any suggestions how to improve this? Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] SQLAlchemy (zope.sqlalchemy) integration
On Jun 4, 2008, at 12:02 PM, Hermann Himmelbauer wrote: Hi, Regarding to the discussion some days ago with the SQLAlchemy Zope3 integration, I still have problems with retrieving the session. I currently use a utility for the engine, which seems to work well. However, for retrieving the session, I tried to use the following pattern (many thanks to Michael Bayer, btw.): database module --- SASession = scoped_session(sessionmaker( transactional = True, autoflush = True, extension = ZopeTransactionExtension())) def getSASession(): SASession.remove() engine = getUtility(ISAEngineUtility).getEngine() s = SASession() s.bind = engine return s In my application, I then use getSASession() to retrieve my session. However, what I think is not that beautiful is the s.bind = engine part. Are there any suggestions how to improve this? FTR, my suggestion here is to configure/tear down sessions upon request boundaries, as described in http://www.sqlalchemy.org/docs/04/session.html#unitofwork_contextual_lifespan . ___ 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 )
Re: [Zope-dev] Deciphering Zope Comments
Shane Hathaway wrote at 2008-6-4 00:01 -0600: ... # SiteManager API. This needs to get deprecated eventually. 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'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. I, too, hope (and expect) so. 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. 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 I have read, thread local variables have been invented and implemented in Zope 3 land and donated to Python. Now, that it is in Python, the original Zope implementation can go away. Maybe, that is the purpose of the zope.thread module? -- Dieter ___ 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 )
[Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration
Hermann Himmelbauer wrote:
Hi,
Regarding to the discussion some days ago with the SQLAlchemy Zope3
integration, I still have problems with retrieving the session. I currently
use a utility for the engine, which seems to work well.
However, for retrieving the session, I tried to use the following pattern
(many thanks to Michael Bayer, btw.):
database module ---
SASession = scoped_session(sessionmaker(
transactional = True,
autoflush = True,
extension = ZopeTransactionExtension()))
def getSASession():
SASession.remove()
engine = getUtility(ISAEngineUtility).getEngine()
s = SASession()
s.bind = engine
return s
In my application, I then use getSASession() to retrieve my session.
However, what I think is not that beautiful is the s.bind = engine part. Are
there any suggestions how to improve this?
You have two options
If you ever need to mix objects from different `sites` into the same
session, you should use an adapter on your root object like:
Sessions = {}
@adapter(MyRoot)
@provider(ISASession)
def getSASession(context):
Session = Sessions.get(context.uid, None)
if Session is None:
Session = Sessions.setdefault(
context.uid,
scoped_session(sessionmaker(
transactional=True, autoflush=True,
extension=ZopeTransactionExtension(),
bind=Engine(context.engine_url) # or getUtility...
))
)
return Session()
And register orm.object_session also if you like to call consistently
session = ISASession(context)
If you don't need to mix objects from different `sites` then you can
register a local utility for ISessionConfig.
def scope():
return getUtility(ISessionConfig).uid, thread.get_ident()
def factory():
engine = Engine(getUtility(ISessionConfig).url)
return create_session(
transactional=True, autoflush=True, bind=engine
extension=ZopeTransactionExtension(),
))
Session = scoped_session(factory, scopefunc=scope)
Then you can just import Session and use:
session = Session()
Laurence
___
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 )
