Chris McDonough wrote: > Iain Duncan wrote: >> On Sat, 2009-09-26 at 01:42 -0400, Chris McDonough wrote: >>> Iain Duncan wrote: >>>>>> 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. ;-) >>>> Hmm, wondering about bfg's look up of views though. Would it be feasible >>>> for me to replace the site manager that bfg uses to look up views, given >>>> that they are named multi-adapters under the hood. ( see I've been >>>> reading! ha ha ) >>> You can do this, it's just essentially replacing the "registry" attribute >>> of >>> the BFG "router" app that represents the application. Sort of. BFG >>> actually >>> uses a subclass of the registry (see registry.py). So you have to replace >>> it >>> with one that has the same methods. You can probably do this in a >>> subscriber >>> to the WSGIApplicationStartedEvent, which receives the router object as an >>> argument. Thereafter, the registry placed on the stack will be the one you >>> placed there. >>> >>> I'd advise against it, though. It smells real bad. >> Hmm, I agree, but I feel like there is a smell either way. ;-) >> >> It seems to me I can either: >> >> A) - create a duplicate of the the same registry in my abstract model >> middleware by using zope.configuration.xmlconfig( same_file_as_bfg ) and >> then know that any utility/adapter queries will get the same things > > This seems like it might be the lesser of two evils.. although I'd be asking > myself these things: > > a) Does the middleware really need a component registry? > > b) If so, does the middleware really need to use the *same* registry as the > applications its in front of? > > c) If so, why is this thing middleware and not part of the application? > (Answering my own question: because there's more than one app, I understand). > >> 2 - find a way to make bfg use the same registry I make in the >> middleware >> >> A) also smells bad to me because I am duplicating the registry, but >> perhaps if I am only programatically *reading* from the registry the >> rest of the time it's the lesser of the two evils? I intend for the >> registry to get populated on startup and then stay static. >> >> In this context, the call chain is my model middleware, pylons, and bfg >> at the end, the bfg app basically acting as a configurable crud thing. I >> realize this is kind of a bent use of bfg, but on reading the bfg docs >> it seemed like the bfg router and views accomplished a whole ton of >> stuff I was just doing badly from scratch in my initial attempts. >> >> I'd be interested in hearing your thoughts on pros/cons of each and why >> in particular you think hijacking the bfg registry with one created in >> middleware would be bad, but I appreciate you no doubt have your own >> stuff to work on! > > To be honest, if there's less than, say, 3K-4K lines of code in the Pylons > project, I'd be tempted port the Pylons code to BFG and just make it all one > BFG app. I assume you've considered and rejected this idea. > > Failing this, maybe you could proxy the Pylons app via the BFG @wsgi_app2 > decorator on some very generic view. At this point, the BFG registry will be > "current" wrt the global ZCA API, so calls in the Pylons apps will get the > "right" registry.
That's this, to be clear: http://docs.repoze.org/bfg/current/api/wsgi.html#repoze.bfg.wsgi.wsgiapp2 > > - C > > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
