[Zope-dev] zope.component.zcml and global registry

[Tres Seaver]

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