Iain Duncan wrote:
> On Sat, 2009-09-26 at 01:04 -0400, Chris McDonough wrote:
>> Iain Duncan wrote:
>>> Ok, so I figured out that if I get the zope.component.globalSiteManager
>>> in my model middleware on ingress, that in bfg I can indeed query it for
>>> registered adapaters and get at that. But in the bfg app, the global
>>> site manager is empty and the siteManager has the stuff from my zcml
>>> file.
>>> So, I think I could do what I need if I knew how to:
>>> - fill the global site manager in middleware from the zcml file
>>> - get bfg to either use that site manager or fold it's contents into the
>>> one that is actively used
>> Apologies, I think you may be on your own.  It's definitely possible, but 
>> the 
>> zope.component ZCML loading design and the general "there can be only one 
>> registry" design of the global ZCA API hurts badly here, as *any* use of 
>> globals does.  It's just an awful design.
> Well I feel better about feeling confused... but not so encouraged. ;-)
> If I could get the 'one-registry-to-rule-them-all' loaded in middelware
> on ingress, is there at least a reasonable way of forcing the bgf app to
> use that registry as it's site manager? 

Nope.  BFG hooks this "hookable" thing when it loads a ZCML file to put it in 
its own registry, and unhooks it when loading is done.  On every request, it 
pushes that registry into a place where it can be found by the global API and 
pops it off when the request is done.  The global registry is never populated 
or consumed.

> Like, I managed to stash the
> middleware created site manager in the environ, and get at it
> successfully from bfg, but it means I'm manually querying adapters like
> so:
> sm = environ['dram.sm']
> sm.queryAdapter( yada yada )

If you've got that far, good on ya.  Any solution you come up with will smell a 
lot like that, so you may have already won. FTR, this is what all interaction 
with any ZCA registry *should* look; the global API is for the birds. ;-)

- C

Repoze-dev mailing list

Reply via email to