Hi folks, the ZCML directives in zope.component register components using the utility method handler, which looks like: def handler(methodName, *args, **kwargs): method = getattr(zope.component.getGlobalSiteManager(), methodName) In our company-specific framework (which is far far from zope3, and only uses the bicycle repair kit), we use different registries per application, similarly to repoze.bfg. Everything works, included code which relies on the zope.component's API, thanks to the hooks on getSiteManager. Those ZCML directives use the getGlobalSiteManager though, which is not hookable and thus we had to reimplement the ZCML directives we need to call getSiteManager instead of getGlobalSiteManager. By default, getSiteManager returns the global registry, so I don't see any obvious reason why the ZCML directives make use of getGlobalSiteManager. repoze.bfg, for example, reimplemented the ZCML directives as we did, but I'd love to be able to use the implementation from zope.component. Any idea? Would you kill me if I propose to change the registration handler to use getSiteManager instead? :) Thanks, Fabio
Hi Fabio
Betreff: [Zope-dev] zope.component.zcml and global registry
Hi folks,
the ZCML directives in zope.component register components using the utility method handler, which looks like:
def handler(methodName, *args, **kwargs): method = getattr(zope.component.getGlobalSiteManager(), methodName)
In our company-specific framework (which is far far from zope3, and only uses the bicycle repair kit), we use different registries per application, similarly to repoze.bfg.
Everything works, included code which relies on the zope.component's API, thanks to the hooks on getSiteManager. Those ZCML directives use the getGlobalSiteManager though, which is not hookable and thus we had to reimplement the ZCML directives we need to call getSiteManager instead of getGlobalSiteManager.
By default, getSiteManager returns the global registry, so I don't see any obvious reason why the ZCML directives make use of getGlobalSiteManager. repoze.bfg, for example, reimplemented the ZCML directives as we did, but I'd love to be able to use the implementation from zope.component.
Any idea? Would you kill me if I propose to change the registration handler to use getSiteManager instead? :)
Not sure if I understand you correct. But what do you think about the following: - implement a new optional attribute useLocal=True in the directive and then configure the directive action and make use of the (local) getSiteManager method. I like to use getGlobalSiteManager by default because this doesn't force a database access and load the local site manager if the site is a local site. My personal goal is to avoid any Zope database access which is not really needed. Because we use MongoDB as object storage and we only have a few items in the Zope database. Things like a local component registry get only rarly used and loaded in our setup. Could this be an alternative concept and fit? Regards Roger Ineichen
Thanks, Fabio _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Hello roger, * 2010-03-03 11:36, Roger wrote:
Not sure if I understand you correct. But what do you think about the following:
- implement a new optional attribute useLocal=True in the directive and then configure the directive action and make use of the (local) getSiteManager method.
I like to use getGlobalSiteManager by default because this doesn't force a database access and load the local site manager if the site is a local site.
I'm not sure what you mean with "doesn't force a database access and load the local site manager". This is the implementation of getSiteManager from zope.component._api: base = None @hookable def getSiteManager(context=None): global base if context is None: if base is None: from zope.component.globalregistry import base return base else: # Use the global site manager to adapt context to `IComponentLookup` # to avoid the recursion implied by using a local `getAdapter()` call. try: return IComponentLookup(context) except TypeError, error: raise ComponentLookupError(*error.args) In our use cases (ZCML registrations), context is None and thus it will simply return the global registry, without any database access. It is the equivalent of getGlobalSiteManager, but it can be hooked (note the @hookable decorator).
Could this be an alternative concept and fit?
This would change the API, my proposed change is back-compatible and does not introduce any new API (because it is equivalent, indeed). Best regards, Fabio
Hi Fabio
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
Hello roger,
* 2010-03-03 11:36, Roger wrote:
Not sure if I understand you correct. But what do you think about the following:
- implement a new optional attribute useLocal=True in the directive and then configure the directive action and make use of the (local) getSiteManager method.
I like to use getGlobalSiteManager by default because this doesn't force a database access and load the local site manager if the site is a local site.
I'm not sure what you mean with "doesn't force a database access and load the local site manager". This is the implementation of getSiteManager from zope.component._api:
base = None @hookable def getSiteManager(context=None): global base if context is None: if base is None: from zope.component.globalregistry import base return base else: # Use the global site manager to adapt context to `IComponentLookup` # to avoid the recursion implied by using a local `getAdapter()` call. try: return IComponentLookup(context) except TypeError, error: raise ComponentLookupError(*error.args)
In our use cases (ZCML registrations), context is None and thus it will simply return the global registry, without any database access. It is the equivalent of getGlobalSiteManager, but it can be hooked (note the @hookable decorator).
Could this be an alternative concept and fit?
This would change the API, my proposed change is back-compatible and does not introduce any new API (because it is equivalent, indeed).
Uhh, I didn't understand your question correct. I was thinking that the getGlobalSiteManager should lookup the local registry. Sorry about that. Regards Roger Ineichen
Best regards, Fabio
On Wed, Mar 3, 2010 at 11:12 AM, Roger <dev@projekt01.ch> wrote:
I like to use getGlobalSiteManager by default because this doesn't force a database access and load the local site manager if the site is a local site.
The database access only happens if a local site is set into the corresponding thread local. But such a site is only set up when traversing over the application root via some events. At the point in the startup process when ZCML is processed, there's no traversal events setup that could cause this and nothing should open the database connection and traverse over it either. So +1 on using getSiteManager instead of getGlobalSiteManager. Hanno
Hi Hanno
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
On Wed, Mar 3, 2010 at 11:12 AM, Roger <dev@projekt01.ch> wrote:
I like to use getGlobalSiteManager by default because this doesn't force a database access and load the local site manager if the site is a local site.
The database access only happens if a local site is set into the corresponding thread local. But such a site is only set up when traversing over the application root via some events.
At the point in the startup process when ZCML is processed, there's no traversal events setup that could cause this and nothing should open the database connection and traverse over it either.
So +1 on using getSiteManager instead of getGlobalSiteManager.
We use a different site setup. In our app the DB root "Application" is the only site. This means if the zope "Application" get traversed my (local) site get traversed. I'm not sure at what time the event will set the site hooks. The worst thing what could happen that the changes in getGlobalSiteManager will add the configuration to the local site. btw, we do something like this in a bootstrap subscriber: def bootstrapXPOSite(event): """Subscriber to the IDataBaseOpenedEvent Setup a site as root Application """ db, connection, root, root_folder = getInformationFromEvent(event) if root_folder is None: # create import bla.bla root_folder = bla.bla.Site(u'The only site') zope.event.notify(zope.lifecycleevent.ObjectCreatedEvent(root_folder)) # add as Application root root[ZopePublication.root_name] = root_folder # commit site to DB transaction.commit() connection.close() zope.event.notify(DatabaseOpenedWithRoot(db)) If all kind of configuration directive processing is done before any kind of DB root access and relevant event handling (e.g. site hook setup) this seems fine to me. If not, then we run into troubles with the changes. Regards Roger Ineichen
Hanno
* 2010-03-03 14:57, Roger wrote:
If all kind of configuration directive processing is done before any kind of DB root access and relevant event handling (e.g. site hook setup) this seems fine to me. If not, then we run into troubles with the changes.
I've tried the patch running the whole ztk test set (including the zopeapp test set) and there are no regressions, so I assume it is safe to apply it to the trunk. I'll wait a week to see if anybody objects to this change, then I'll commit it to the trunk. Thanks, Fabio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fabio Tranchitella wrote:
* 2010-03-03 14:57, Roger wrote:
If all kind of configuration directive processing is done before any kind of DB root access and relevant event handling (e.g. site hook setup) this seems fine to me. If not, then we run into troubles with the changes.
I've tried the patch running the whole ztk test set (including the zopeapp test set) and there are no regressions, so I assume it is safe to apply it to the trunk.
I'll wait a week to see if anybody objects to this change, then I'll commit it to the trunk.
If the tests all pass, then I would say go ahead and commit it now, but add tests to verify that the new feature works as you expect. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuOxu4ACgkQ+gerLs4ltQ76bACfVRGv0CUCGfpaAdZRqEbwl0lm DyMAoMiT6qv+UXrjH/fVzJAf+Ir42bK/ =GTRq -----END PGP SIGNATURE-----
* 2010-03-03 21:35, Tres Seaver wrote:
If the tests all pass, then I would say go ahead and commit it now, but add tests to verify that the new feature works as you expect.
Committed with tests. Best regards, Fabio
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests.
If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file: - The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry. Thanks, Fabio
On Mon, Mar 8, 2010 at 9:18 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests.
If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file:
- The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry.
Is this a feature release ? Regards, Baiju M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Baiju M wrote:
On Mon, Mar 8, 2010 at 9:18 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests. If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file:
- The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry.
Is this a feature release ?
It seems arguable either way to me: the old behavior (forcibly populating the global registry instead of the hooked registry) could easily be construed as a bug. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuVLf8ACgkQ+gerLs4ltQ4dNACgtOjXaYXEZR2kTTsXnyDKGokT zuAAoL/9WZ4RtC4CBq+I7gV4k6iokoRj =Piih -----END PGP SIGNATURE-----
Hi Tres
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Baiju M wrote:
On Mon, Mar 8, 2010 at 9:18 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests. If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file:
- The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry.
Is this a feature release ?
It seems arguable either way to me: the old behavior (forcibly populating the global registry instead of the hooked registry) could easily be construed as a bug.
Probably you have a very different point of view to this changes. Let me explain what I think about that. We have two kind of registries in zope a global/non persistent and local/persistent in local sites. The setSite hooks forces to set the right context for component lookup. Note, I mean component lookup, and not component registry lookup or register components! ZCML based configuration actions are not persistent and can't get registered in a local component registry. This is the reason why we didn't use the hooked getSiteManager method for this configuration actions. What this changes really does is, it allows to set a site which forces to use another site manager which contains a different component registry. I don't think setup another site is the right concept to use another component registry. Probably there should be an explicit call for the IComponents utility in this case. btw, if you like to register actions for another registry then the global registry, there is a concept implemented in z3c.baseregistry. It does exactly what the changes forces to do without the possible sideeffect of register non peristent actions in a local persistent component registry. With some lines of ZCML every action could register it's handler to such another global component registry. e.g. <utility component="my.global.Registry" provides="zope.component.interfaces.IComponents" name="other" /> <zope:registerIn registry="my.global.Registry"> <!-- include your ZCML here --> </zope:registerIn> Now, if your site provides the 'other' IComponents utility, your fine and you will get what you need. This concept explicit allows to register components in a component registry and does not invoke a running application in any way. In my point of view, this changes/feature is implemented as simple as possible and not done right. If you configure a system during startup, in our case with ZCML actions, it's really not a good idea to change the running system itself for make this possible. Another point, reloading ZCML actions after a system startup e.g. from the UI is probably not possible anymore. Then we whould have to call setSite(None) and this, on a running system, whould force to loose the local components registry at the same time. But anyway, if nobody objects I'm fine with this changes. I just like to make sure everybody really knows the sideeffects of this changes and hope we're not having problems later with this feature. Regards Roger Ineichen
On Mon, Mar 8, 2010 at 7:23 PM, Roger <dev@projekt01.ch> wrote:
Another point, reloading ZCML actions after a system startup e.g. from the UI is probably not possible anymore. Then we whould have to call setSite(None) and this, on a running system, whould force to loose the local components registry at the same time.
I'm not sure if there's other code that implements this, but if you look at the way I do it in plone.reload [1], you'll notice that it already does an explicit getGlobalSiteManager call and a setSite(None). The site is set again on the next request, when traversing over the local site object. The code also has to minimize the ZODB cache, or the local site will have some cached info that might have been invalidated by the global changes. So I don't see this as a counter argument :) Hanno [1] http://svn.plone.org/svn/plone/plone.reload/trunk/plone/reload/zcml.py
Hi Hanno
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
On Mon, Mar 8, 2010 at 7:23 PM, Roger <dev@projekt01.ch> wrote:
Another point, reloading ZCML actions after a system startup e.g. from the UI is probably not possible anymore. Then we whould have to call setSite(None) and this, on a running system, whould force to loose the local components registry at the same time.
I'm not sure if there's other code that implements this, but if you look at the way I do it in plone.reload [1], you'll notice that it already does an explicit getGlobalSiteManager call and a setSite(None). The site is set again on the next request, when traversing over the local site object. The code also has to minimize the ZODB cache, or the local site will have some cached info that might have been invalidated by the global changes.
So I don't see this as a counter argument :)
There is allways a way to do things ;-) Tweak a running system itself for reload configuration is probably not the best one. As more as I think about what Fabio changed and what really happens, I think it's just a missing API which splits the ZCML action configuration and the running system into different parts. But since you're telling that reload patterns can work with this changes, I think this is good news. Regards Roger Ineichen
Hanno
[1] http://svn.plone.org/svn/plone/plone.reload/trunk/plone/reload/zcml.py
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger wrote:
Hi Tres
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Baiju M wrote:
On Mon, Mar 8, 2010 at 9:18 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests. If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file:
- The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry. Is this a feature release ? It seems arguable either way to me: the old behavior (forcibly populating the global registry instead of the hooked registry) could easily be construed as a bug.
Probably you have a very different point of view to this changes. Let me explain what I think about that.
We have two kind of registries in zope a global/non persistent and local/persistent in local sites. The setSite hooks forces to set the right context for component lookup. Note, I mean component lookup, and not component registry lookup or register components!
ZCML based configuration actions are not persistent and can't get registered in a local component registry. This is the reason why we didn't use the hooked getSiteManager method for this configuration actions.
What this changes really does is, it allows to set a site which forces to use another site manager which contains a different component registry. I don't think setup another site is the right concept to use another component registry. Probably there should be an explicit call for the IComponents utility in this case.
btw, if you like to register actions for another registry then the global registry, there is a concept implemented in z3c.baseregistry. It does exactly what the changes forces to do without the possible sideeffect of register non peristent actions in a local persistent component registry. With some lines of ZCML every action could register it's handler to such another global component registry.
e.g. <utility component="my.global.Registry" provides="zope.component.interfaces.IComponents" name="other" /> <zope:registerIn registry="my.global.Registry"> <!-- include your ZCML here --> </zope:registerIn>
Now, if your site provides the 'other' IComponents utility, your fine and you will get what you need.
This concept explicit allows to register components in a component registry and does not invoke a running application in any way.
In my point of view, this changes/feature is implemented as simple as possible and not done right.
If you configure a system during startup, in our case with ZCML actions, it's really not a good idea to change the running system itself for make this possible.
Another point, reloading ZCML actions after a system startup e.g. from the UI is probably not possible anymore. Then we whould have to call setSite(None) and this, on a running system, whould force to loose the local components registry at the same time.
But anyway, if nobody objects I'm fine with this changes. I just like to make sure everybody really knows the sideeffects of this changes and hope we're not having problems later with this feature.
The Highlander model ("there can be only one") for ZCML-configured non-persistent component registries is self-limiting. BFG is an existence proof that multiple non-persistent registries, each configured via ZCML, can work and be useful: it allows us to run multiple, unrelated apps within a single process, without mingling their configurations. Note that BFG doesn't use persistent registries at all. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuVSL4ACgkQ+gerLs4ltQ5HxwCgp9melxb/ZBAer7nPOhh1Lo0b OhsAn0pxFprn3GlC740+pjNSdbNhkHh9 =b3kb -----END PGP SIGNATURE-----
Hi Fabio
Betreff: Re: [Zope-dev] zope.component.zcml and global registry
* 2010-03-04 20:51, Fabio Tranchitella wrote:
Committed with tests.
If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file:
A bugfix probably for your app, but a feature for zope packages
- The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry.
I've tested our app which uses the local site as application root, e.g. db, connection, root, root_folder = getInformationFromEvent(event) root_folder = foo.bar.LocalSite() root[ZopePublication.root_name] = root_folder It seems that this is fine and the local (root app) site registry get never touched during configuration setup. I hope nobody is using setSite in the wrong place, then this new feature will horribly break their applications. Regards Roger Ineichen
* 2010-03-08 17:51, Roger wrote:
A bugfix probably for your app, but a feature for zope packages
I thought it is a bug fix (I see no reason why it used the global registry before, because it is totally equivalent) and it does not change the API and the semantic of the ZCML directives. I don't mind releasing as a major release, though.
I hope nobody is using setSite in the wrong place, then this new feature will horribly break their applications.
TBH, I see no possibility to break anything with such a change, unless you really expect to work it in this way (eg. hooking getSiteManager *before* loading a ZCML file). I'll wait till the week-end to release it, so everybody has the opportunity to have a word on this topic. Best regards, Fabio
* 2010-03-08 18:16, Fabio Tranchitella wrote:
I'll wait till the week-end to release it, so everybody has the opportunity to have a word on this topic.
I've released zope.component 3.9.3 with the change I discussed on the list in the last couple of weeks (ZCML registrations using getSiteManager instead of getGlobalSiteManager) and updated the ztk.conf. Best regards, Fabio
On 3/15/10 11:52 AM, Fabio Tranchitella wrote:
* 2010-03-08 18:16, Fabio Tranchitella wrote:
I'll wait till the week-end to release it, so everybody has the opportunity to have a word on this topic.
I've released zope.component 3.9.3 with the change I discussed on the list in the last couple of weeks (ZCML registrations using getSiteManager instead of getGlobalSiteManager) and updated the ztk.conf.
Thanks for this work Fabio. - C
On Wednesday 03 March 2010, Fabio Tranchitella wrote:
Any idea? Would you kill me if I propose to change the registration handler to use getSiteManager instead? :)
Mmh, I implemented z3c.baseregistry a long time ago, which allows you to register components into arbitrary registries. http://svn.zope.org/z3c.baseregistry/trunk/src/z3c/baseregistry/README.txt?r... Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
* 2010-03-03 15:33, Stephan Richter wrote:
Mmh, I implemented z3c.baseregistry a long time ago, which allows you to register components into arbitrary registries.
http://svn.zope.org/z3c.baseregistry/trunk/src/z3c/baseregistry/README.txt?r...
Thanks for the link; z3c.baseregistry depends on zope.site, which depends on a lot of packages we don't use, though. Also, I think my use case it quite different, because we don't use ZODB, we rely on WSGI and we have one-python-process-multiple-applications setup. Fabio
On Wednesday 03 March 2010, Fabio Tranchitella wrote:
Thanks for the link; z3c.baseregistry depends on zope.site, which depends on a lot of packages we don't use, though.
I think you can make it easily zope.site independent.
Also, I think my use case it quite different, because we don't use ZODB, we rely on WSGI and we have one-python-process-multiple-applications setup.
The documentation focuses on the ZODB, because that was the use case I had in mind, but it really fills up any registry you want to, so there is nothing ZODB specific about the package. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
participants (7)
-
Baiju M -
Chris McDonough -
Fabio Tranchitella -
Hanno Schlichting -
Roger -
Stephan Richter -
Tres Seaver