Martin Aspeli wrote:
> Chris McDonough wrote:
>> I think we have to divorce the requirement from "the ZCA".
>> The requirement:
>> - an attribute of an instance of the class
>> "zope.component.registry.Components" which is dictionarylike
>> (accepts any key type, any value type).
>> If I can get that, I'd be happy, regardless of what's happening under the
>> If you want to turn this into a component lookup, that'd be fine; if
>> that'd be fine too.
>> That said, if I had just added a separate attribute ithat is a dict inside
>> Components constructor (instead of subclassing Components from dict) and
>> checked it in, would anyone have cared? This isn't a feature that any Zope
>> developer really *has* to use, it's just a feature that provides
>> between future BFG apps and Zope. It'd also be possible to change its
>> implementation in the future if we thought it should use utility
>> We already have this situation. The Components class is already a wrapper
>> has an "adapters" attribute (an instance of a zope.interface
>> and a "utilities" attribute (an instance of something else). All adapter
>> utility state is kept in these substructures.
>> While maybe it would be wrong to refer to the things manipulated via a
>> object as an additional attribute of the class as "utilities", adding
>> attribute and exposing a wrapper API is a pattern that is already embraced
>> the class.
> If it were just another attribute analogous to .utilities and .adapters,
> calling it "utils" or "utilities" would be misleading, because it's not
> actually a utility. You could call it "settings" or something.
> However, you'd still need to implement support for __bases__ and all
> that: getSiteManager() will return the nearest site manager, so if it
> was just a "dumb" dictionary you'd get a KeyError as soon as you'd
> traversed over a site (e.g. into a Plone site), thus setting a local
> site manager. You *could* use getGlobalSiteManager() every time, but
> then people have to know that .settings is only on the global site manager.
> And you'd still have to do all the wiring in Python, or invent a new
> ZCML directive. Wiring at module import time is not ideal.
> Conversely, if you implement it so that it's backed by named utilities
> providing Interface, then it's just a convenience and we still have the
> same override and introspection mechanisms we've always had for
> utilities. That sounds like a good bit of "internal consistency" to me.
I fear it was for naught, sorry.
Adding an attribute is unsightly and turning this into a component problem
doesn't have enough immediate gain. The BFG registry will just continue to be
a dict subclass.
If Zope folks later want to use libraries that come from BFG-land (particularly
libraries that have ZCML directives), they'll just need to deal with code that
wants to use the dict API against the component registry.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -