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  

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!

thanks again,

Repoze-dev mailing list

Reply via email to