On 2/5/10 7:20 AM, Andrey Popp wrote:
> I want to design web application, which can be installable, like trac.
> For the first time I've made "my own framework" around
> repoze.component+repoze.configuration with werkzeug for WSGI stuff.
> But now, I want to switch to repoze.bfg. So, I have some questions.
> In my framework each installation represented by directory with
> settings file and component configuration file. There are also
> subdirectory for logs, pidfile and other stuff. In settings I have
> list of packages to import and to read component configuration from.
> So, installed application represented by Environment object (some kind
> of Configurator in repoze?) with repoze.component.Registry and parsed
> settings file.
> But I do not understand how to achieve the same functionality with
> repoze.bfg. -- should I treat each installed instance of my
> application as setuptools-enabled python package, for example? How I
> can get Configurator read ZCML from my installation and how to inject
> my settings file into application?
I'd suggest that if you have an "instance" per deployment, an instance might be
represented via a directory and it might look something like this:
|-- var (dir)
The configure.zcml might look something like this:
It would include all the packages it needs, in other words.
The app.ini might include an "app" section that looked like so:
use = egg:mysoftware#app
configure_zcml = %(here)s/configure.zcml
.. this would point at a paste app entry point something like:
rom repoze.bfg.configuration import Configurator
from mysoftware.models import get_root
def app(global_config, **settings):
""" This function returns a WSGI application.
It is usually called by the PasteDeploy framework during
config = Configurator(root_factory=get_root, settings=settings)
zcml_file = settings.get('configure_zcml', 'configure.zcml')
Then you'd invoke the application via "paster serve app.ini". Note that
**settings gets the settings from the app.ini app section.
See also http://docs.repoze.org/bfg/1.2/narr/project.html
There are about a million ways to slice this; this is one possible way.
> Another goal for me is to run my application under eventlet/gevent (it
> is coroutine based async network library). The possible problem here
> is extensive use of threadlocals in repoze.bfg. But I think it can be
> resolved by monkey patching threadlocals to make them greenletlocals.
Before trying to resolve anything using a thread local, BFG itself tries hard
to obtain a "local" version of the registry and request (via e.g.
"request.registry"). I think in practice this means that if you don't use any
thread locals in your app, you probably don't need to worry about it.
The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book
Repoze-dev mailing list