-----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-----