Iain Duncan wrote:
>>> 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. =)

Passing an API directly down through middleware to apps is the topic of much 
hand wringing:


It's still convenient, and ultimately your call, though.

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

Grain of salt and all, considering the source, but I'm pretty sure that BFG is 
a much better fit for "developing clients" with no prior experience with Pylons 
than is Pylons, all other things being equal.

This is because BFG has a mechanism for your clients to add and override views 
from an external package without forking your code, particularly when traversal 
is used.  (It's still possible to override and add views that use "url 
dispatch" (aka routes) in a BFG app, but because routes need ordering, it's not 
always possible to do this without cutting and pasting *all* the routes (ZCML) 
into a customer package and having them add/change them there.)

See also http://docs.repoze.org/bfg/1.0/narr/extending.html

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

This seems like it might be the sanest path.  Sorry I didn't think of it 

- C

Repoze-dev mailing list

Reply via email to