On 6/25/09 7:10 PM, Iain Duncan wrote:
> On Thu, 2009-06-25 at 18:39 -0400, Tres Seaver wrote:
>> 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-
>>    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 
WSGI application; you should be able to call it without adverse consequence 
any other WSGI application.

- C
Repoze-dev mailing list

Reply via email to