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,
>>>>> pushes that registry into a place where it can be found by the global API
>>>>> pops it off when the request is done. The global registry is never
>>>>> 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
>>>>>> 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
>>>>> 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
>>> the BFG "router" app that represents the application. Sort of. BFG
>>> uses a subclass of the registry (see registry.py). So you have to replace
>>> with one that has the same methods. You can probably do this in a
>>> 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
>> 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