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.

- C

Repoze-dev mailing list

Reply via email to