On 5/7/09 5:28 PM, Shane Hathaway wrote:
>> 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.
> True. Is it time to write repoze.configuration? ;-)
Ha.. sadly, already done, mostly:
I haven't really expected it to see the light of day but it does indeed work,
eschews zope.schema and returns those tuples.
>> 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).
> I agree. However, I hesitate to give up the idea of using the
> configuration machinery to populate other kinds of registries in
> addition to the zope.component registry. If we gain the ability to
> populate the zope.component registry in a non-global way, I want to be
> able to populate other registries in a non-global way too. :-)
Well, sure, handlers that are used in a config file are free to do as they
but handlers that do want to populate some registry should probably just have
scope-local access to it. If there are two registries that need populating,
just attach both of them to the context. Or if a handler doesn't use it, just
reach out and populate some module scope thing or whatever.
> One way to do that would be to add one more indirection to your plan.
> Instead of storing the zope.component registry as an attribute of the
> configuration context, the configuration context could hold an attribute
> with a dictionary of named registries. So handlers would grab the
> component registry as "context.registries['zope.component']".
Sure, that'd work. But I think one thing to keep in mind is that it's not
really that common for arbitrary directives to be used together, so maybe
explicit namespacing is not necessary and a directive can just assume the
registry it wants is attached to the context under some well-known name. Then
if some system wants offer the use of two directives that populate separate
registries, it can just manufacture and offer up a context that has both on it.
Repoze-dev mailing list