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
>>>> 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 of
>> 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
Repoze-dev mailing list