On 6/25/09 7:10 PM, Iain Duncan wrote:
> On Thu, 2009-06-25 at 18:39 -0400, Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Iain Duncan wrote:
>>> I'm new to zope/repoze etc. I'm working on something where I want
>>> ultimately to be able to drop it into any wsgi aware environment and
>>> have it *just work*. I plan on this project being a stupidly well
>>> document stand alone admin interface scaffold for cases where explicit
>>> is better than auto-generated or reflected. ( For example. validation
>>> schemas, form schemas, view schemas, all with be declared data-mapper
>>> style )
>>> I was going to do it with just paste tools but it seems like I'm
>>> spending too much time trying to write subpar dispatching
>>> mechanisms. ;-) I should piggyback on something, and I *think this means
>>> it should have:
>>> - no thread locals: all working objects are instantiated per request so
>>> users can use self without fear
>>> - no framework magic super globals: no worrying about how to get
>>> framework provided magic into your project that isn't a framework
>>> ( ie pylons global request and response objects )
>>> - minimal dependencies on third party libraries, third party integration
>>> to be provided by middleware
>>> - wsgi all the way down, use of the popular wsgi libraries that other
>>> frameworks are using where possible
>>> - easy for the client user to understand when code is being called by
>>> I'm heavily in the boxes and arrows stage, designing the client api, and
>>> experimenting with nice ways to implement it. I would love to hear
>>> feedback from experts on bfg and zope on whether they think bfg is a
>>> good potential for the above and why/why-not.
>> Sounds perfect for BFG to me:
>> - - We make only one tightly-controlled use of thread-locals: the
>> zope.component registry hook gets set with the application-specific
>> component registry at the beginning of the request, and cleared at the
>> - - There are no super-globals in BFG: we pass in context, request etc.
>> to view functions, with the expectation that they will pass them to
>> any helpers which need them.
>> - - BFG works hard to keep its dependencies to a minimum. Here is the
>> set of eggs installed into an empty virtual environment as follows:
>> $ /path/to/virtualenv --no-site-packages /tmp/bfg
>> $ /tmp/bfg/bin/easy_install \
>> --index-url=http://dist.repoze.org/bfg/current/simple repoze.bfg
>> $ ls -c /tmp/bfg/lib/python2.6/site-packages
>> - - BFG relies on Paste, PasteDeploy, PasteScript, and WebOb for its
>> WSGI support.
>> - - BFG apps tend to have most application code in self-contained
>> view functions, which are found via simple traversal or URL dispatch.
>> Many such views are only an editor buffer long, or less (the longer
>> ones make some kind of form validation framework attractive).
> Thanks Tres. Yes I'm getting quite excited about chucking out my own
> attempt at a dispatcher! Way too much coding that wasn't really what I
> wanted to be spending time on...
> Can you think of any instances or gotchas where mixing up bfg and pylons
> apps may be problematic? Specifically I am thinking that my admin app
> will likely be a component used extensively in Pylons projects.
It's a bit brainbusting to think about, but sure. Why not. A BFG app is just
WSGI application; you should be able to call it without adverse consequence
any other WSGI application.
Repoze-dev mailing list