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 >>> whom >>> >>> 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 >> end. >> >> - - 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 >> easy-install.pth >> pytz-2009g-py2.6.egg >> zope.i18nmessageid-3.5.0dev_optional_c-py2.6-linux-i686.egg >> zope.schema-3.5.4-py2.6.egg >> sourcecodegen-0.6.9-py2.6.egg >> zope.i18n-3.7.0-py2.6.egg >> Paste-1.7.2-py2.6.egg >> PasteDeploy-1.3.2-py2.6.egg >> zope.configuration-3.6.0-py2.6.egg >> zope.event-3.4.1-py2.6.egg >> zope.testing-3.7.3-py2.6.egg >> chameleon.core-1.0b36-py2.6.egg >> chameleon.zpt-1.0b17-py2.6.egg >> PasteScript-1.7.3-py2.6.egg >> WebOb-0.9.6.1-py2.6.egg >> zope.interface-3.5.1-py2.6-linux-i686.egg >> zope.component-3.6.0-py2.6.egg >> repoze.zcml-0.3-py2.6.egg >> zope.deprecation-3.4.0-py2.6.egg >> repoze.lru-0.3-py2.6.egg >> martian-0.12dev_ignore_pyc_branch-py2.6.egg >> repoze.bfg-1.0a3-py2.6.egg >> setuptools-0.6c9-py2.6.egg >> setuptools.pth >> >> - - 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 a WSGI application; you should be able to call it without adverse consequence from any other WSGI application. - C _______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev