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:
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).
Repoze-dev mailing list