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 > <kob...@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 _______________________________________________ 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 )
