On 5/7/09 3:44 PM, Shane Hathaway wrote:
> Chris McDonough wrote:
>> c) handlers actually just *returned* something rather than being
>> called for their side effects.
> The thing the handler returns could implement the IConfigurationAction
> interface described here:
> http://wiki.zope.org/zope3/ReusableActions

Or just make it simple, and return a tuple of (callback, discriminator).  Or a 
sequence of like [(callback, discriminator), (callback, discriminator), <etc>], 
as you say.

>> It's also completely bizarre that a ZCML handler has no easy access to
>> the registry being populated except via getSiteManager().
> Well, the purpose of a handler is to populate some global registry, not
> necessarily the component architecture registry, so I can see the
> reasoning behind that.

But it would have been easy for the ZCML support in zope.component to use a 
different kind of "context" that just had the registry as an attribute.  Then 
you could actually use ZCML configuration to populate a *particular* registry, 
instead of "whatever happens to be returned by getSiteManager()".  Use of 
getSiteManager() causes apps to need to do a number of suspect thread locking 
hacks now if they want to run two otherwise unrelated 
zope.configuration+zope.component-using packages in the same process.  It's 
becoming more frequent that there isn't "one global registry" (it should have 
never been zope.component's job to advertise one, but instead an application 
that *uses* zope.component might choose to do so).

- C

Repoze-dev mailing list

Reply via email to