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['']
>>>>>> 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  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:

> - C
> _______________________________________________
> Repoze-dev mailing list

Repoze-dev mailing list

Reply via email to