> > 
> > 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).

Well, as you guessed, I'm trying to move the domain model and all domain
specific code and configuration out into one place so it can be used by
multiple engine-apps. It also seems to me to be a good way of hedging my
bets on *how* the persistence is handled. What I'm happy about is that
now the pylons code and bfg code don't care what the domain model uses,
sqlalchemy, zodb, xml, whatever. They just get the model off the wsgi
env and call it's methods, and I can retool the model really easily to
be used in other contexts and applications. It seems to be doing what I
want, so I think I can live with the duplicate but identical registry
smell if it's an acceptable evil, at least for now. =)


> 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.

Not rejected, more keeping my options open. There are a lot of bits of
Pylons I find useful, though I really like bfg's architecture. Really
I'm hoping for Pypes to make this all academic, and I guess right now
I'm just trying have my cake and eat it too. There is also a matter of
some 'developing-clients' wanting to be able to add their own read-only
controllers and views, and I think giving them access to the domain
model in simple pylons controllers is easier than having them try to
understand my bfg code. So the admin code uses my bfg code, but I want
them to be able to make extra views easily without knowing bfg.

> 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.

This is kinda what I'm doing, but the other way around. ( There's a
pylons controller that calls my bfg wsgi callable ). Maybe I did it
backwards. I'll have to think on that. Maybe it wouldn't matter who did
what first. hmmm. 

Thanks for all the food for thought!

Repoze-dev mailing list

Reply via email to