I agree this is an awesome direction to go in. I've always thought of
configuration myself as a refactoring done when the app gets complex
enough. Starting off with the assumption that your app will get
complex enough to warrant xml files/ runtime dependencies is a hard
sell when you are starting an app. Not requiring it lowers the
barriers to entry considerably.
A couple of comments.
#1 in the imperative configuration example, I'm having trouble myself
making the mental connection between the configured views and this
implicit root model (or are we calling it context now) object. Is it
possible to show something more explicit in the code example? or maybe
another one that shows using an explicit context traversal
#2 I remember reading docs a few months ago, and deciding for myself
to ignore all the decorators for views because it other docs said you
can't reuse/extend your application if you use decorators, only zcml
config would work. I'm assuming that this is applicable for the
imperative configuration as well? Meaning, if you use imperative
config, your abilities to extend that application are limited?
That's all I got.
On Sat, Nov 28, 2009 at 6:24 AM, Tim Hoffman <zutes...@gmail.com> wrote:
> Hi Chris
> I think this is a good direction to go in. I am already starting to
> do something similair this with repoze (I am still on 1.0.1) but plan
> to upgrade in the next few weeks,.
> The advantage of this style of configuration really comes into its own
> when you are running on appengine.
> With appengine you really can't rely on long running apps, so being
> able to defer some of the declerations/registrations until you
> actually need them
> (for instance only bother registering stuff for an admin user if an
> admin user is logged in) is really important because its startup time
> of a cold instance
> that will kill you at times.
> Using ZCML means is difficult to choose when to register things
> (without jumping through hoops) and view decorators are just as bad.
> Thanks for the great work.
> On Sat, Nov 28, 2009 at 1:57 PM, Chris McDonough <chr...@plope.com> wrote:
>> Hi folks,
>> I've been working on the next minor revision to repoze.bfg, which will be
>> 1.2 will be a slightly more important release than the previous 1.1 release,
>> because it involves exposing an "imperative" API for configuration (adding
>> routes/views, etc).
>> In particular, it means that the simplest repoze.bfg application can be
>> represented as a single file:
>> from webob import Response
>> from wsgiref import simple_server
>> from repoze.bfg.configuration import Configurator
>> def hello_world(request):
>> return Response('Hello world!')
>> if __name__ == '__main__':
>> config = Configurator()
>> app = config.make_wsgi_app()
>> simple_server.make_server('', 8080, app).serve_forever()
>> As far as I can tell, aside from package dependencies, such a configuration
>> mode puts repoze.bfg in the same category as "microframeworks" (such as
>> and Tornado), because applications can start as a single file, then evolve
>> a package, then maybe "grow" declarative configuration in the form of ZCML,
>> so on. repoze.bfg, on the other hand, has a good deal of functionality that
>> microframeworks lack, so I like to think of this functionality as sort of the
>> "best of both worlds" feature.
> Repoze-dev mailing list
Thomas G. Willis
Repoze-dev mailing list