A first stab at the translators is up on github at http://github.com/teepark/django/tree/50b1e97cec14221a846a6338c40f585e40b76960/django/wsgi
I've done django views -> wsgi apps, wsgi apps -> django views, and django middleware -> wsgi middleware. i still think that going from wsgi middleware to django middleware would be impossible, but i intend to write a translator of wsgi middleware to django view decorators. it also needs more tests. A couple of sticky points I have hit so far: 1. some of the information required in a WSGI environ dictionary isn't necessarily available to django (SERVER_PROTOCOL (HTTP version 1.0 or 1.1), wsgi.multithread, wsgi.multiprocess) - I used SERVER_PROTOCOL 1.1, multithread True, multiprocess True as I think those are the more demanding answers, so safer since we don't know 2. process_view in django middleware - when turning it into a wsgi middleware, there is no view, so what to do with it? - my answer right now is go ahead and call it, passing it the wrapped wsgi app. i'd love comments or suggestions. travis On Mar 31, 1:29 pm, Travis Parker <travis.par...@gmail.com> wrote: > On Tue, Mar 31, 2009 at 1:12 PM, Waylan Limberg <way...@gmail.com> wrote: > > > On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker <travis.par...@gmail.com> > > wrote: > > > [snip] > > > > 2. settings (views -> apps, dj middleware -> wsgi middleware) > > > i don't have nearly as nice a proposal for dealing with this. there > > > are a lot of django views and middleware out there that would be nice > > > to have usable as wsgi components but which require > > > django.conf.settings to work. if they are going to go into a wsgi > > > environment though, it seems a little strange to require a > > > DJANGO_SETTINGS_MODULE environment variable and a django-style > > > settings.py. i don't have any great ideas. open for suggestions. > > > [snip] > > > It seems to be a little known/remembered fact that > > DJANGO_SETTINGS_MODULE and settings.py are not required to use django > > code that requires settings. Settings can actually be configured > > manually within python code calling settings.configure(). This way, > > you only actually set settings that you need. In fact, outside of the > > strict situation of a django project, it is the only way I deal with > > settings when using parts of django. > > > See here for details:http://www.djangobook.com/en/1.0/appendixE/#cn57 > > > However, the trick is that you can only call settings.configure() once > > and it's possible that multiple middleware will need settings. On top > > of that, the user may use some of those middlewhere and not others > > and/or change the order of the middlewhere. You'll need some way to > > work out whether configure has been called for each middlewhere and > > only call it the first time. Not fun, but it's got to be better than > > dealing with DJANGO_SETTINGS_MODULE and settings.py. > > > -- > > ---- > > \X/ /-\ `/ |_ /-\ |\| > > Waylan Limberg > > perfect! thanks. the boolean settings.configured seems to indicate whether > it has been configured, so every middleware/app can just check that and > configure() if it hasn't been done yet. > > checking off #2, which I expected to be the hard one. > > travis --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
