Martin Aspeli wrote: > Chris McDonough wrote: > >> 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. > > If you're going down this route, my suggestion would be to not (ab)use > the ZCA site manager object for this at all. I'd have it be something > separate you access via a getConfigRegistry() or whatever. Threadlocals > are easy enough to set up.
Any app using more than one thread local for objects that have the same "scope" tends to make for a pretty rotten testing experience (see Pylons). We already have the right number of objects to hold app config: one; it's the ZCA registry. Making the registry into a dict is the simplest solution to the problem defined in the "defending design" document. If some BFG-centric library becomes a runaway success, and some Zope user wants to use it in Zope, Zope will need to deal with it, or he will need to change the library to not use the feature. That's fine. - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )