Thanks for quick answer, I've got the point.
First, sorry for my stupid questions -- all that I've asked are
described in documentation.
After using django and others, repoze.bfg looks like real framework. Thanks!
On Fri, Feb 5, 2010 at 5:40 PM, Chris McDonough <chr...@plope.com> wrote:
> On 2/5/10 7:20 AM, Andrey Popp wrote:
>>
>> Hello.
>>
>> 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:
>
> myinstance---/
> |
> |-- var (dir)
> |
> |-- configure.zcml
> |
> |-- app.ini
>
> The configure.zcml might look something like this:
>
> <configure ...>
> <include package="repoze.bfg.includes"/>
> <include package="mysoftware"/>
> <include package="mypackage1"/>
> <include package="mypackage2"/>
> </configure>
>
> It would include all the packages it needs, in other words.
>
> The app.ini might include an "app" section that looked like so:
>
> [app:myinstance]
> 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
> ``paster serve``.
> """
> config = Configurator(root_factory=get_root, settings=settings)
> config.begin()
> zcml_file = settings.get('configure_zcml', 'configure.zcml')
> config.load_zcml(zcml_file)
> config.end()
> return config.make_wsgi_app()
>
> 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.
>
> - C
>
> --
> The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book
>
--
С уважением, Андрей Попп.
+7 911 740 24 91
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
