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.

- C
Repoze-dev mailing list

Reply via email to