[Zope-dev] make zope.component.registry.Components inherit from dict?
matthew at matthewwilkes.co.uk
Mon Nov 23 23:53:12 EST 2009
> You may have Zope Component Developer's Eyes, a common disease in
> these parts. ;-)
The goggles, they do nothing.
> Under the hood, the system does something like this when a root
> factory needs to be registered:
> from repoze.bfg.interfaces import IRootFactory
> from zope.component import getSiteManager
> reg = getSiteManager()
> reg.registerUtility(root_factory, IRootFactory)
> Then when the system needs to look it up again, it needs to do this:
> root_factory = getUtility(IRootFactory)
> If you notice, there is no "key" for this utility other than the
> IRootFactory interface (it's unnamed). In this case, also, there
> will never be a registration made against a subclass of
> IRootFactory. In this scenario, if we weren't using ZCA at all,
> we'd probably do something like this:
> reg = get_some_registry()
> reg['root_factory'] = root_factory
> In a system like this, there are no interfaces; the string
> 'root_factory' performs the same job as the IRootFactory interface
> for registration and lookup. I'd like to make the ZCA registry
> operate like this. There's really no reason for there to be an
> interface hanging around to represent this thing: we're using the
> ZCA as a complicated dictionary here.
Right, but I think mixing the two is just going to be confusing. Your
alternative spelling may well be useful, but only if it works within
the confines of the ZCA itself, otherwise you're just hijacking the
component root for your own (nefarious) purposes.
A lookup keyed entirely on strings and not interfaces is perfectly
possible using the ZCA, just register your utility to provide
z.i.Interface and name it. Your semantics are the same as the simple
dictionary use-case, but it doesn't force people to choose one means
of access over another.
Creating shim methods for the dict-interface (or a useful subset)
could hook in registration, querying and unregistration of utilities
in a vaguely sensible way.
But, here is where the ZCA eyes come back into play, I wouldn't add
this to the ZCA itself. One reason being that Hanno's been working on
a more useful persistent component root for Zope that brings in bits
of OFS, hooking a dict in there would just be confusing.
So, if only there was a way of specifying a new set of functions and
defining a way of mapping them onto an existing object…
I'd say make an adapter that adds the dict interface as a wrapper
around named utilities and provide that to BFG users. That way you
don't pollute the namespace of the ZCA object, interoperability with
other code is maintained and you get your user-friendly interface.
More information about the Zope-Dev