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