-----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). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKQ/yK+gerLs4ltQ4RAve2AJ9ACpSHLc3GkEBoUIJhTqynOmC5oQCg2UmA 9TtnaCwGKkXpAFs87f26gWk= =7jMV -----END PGP SIGNATURE----- _______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev