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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
