> > > > 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. =) <snip> > 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! Iain _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
