On Mar 31, 12:04 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker <travis.par...@gmail.com>wrote:
>
>
>
>
>
> > hello django devs,
>
> > It was nice to meet a few of you at pycon. I talked briefly with jacob
> > about a plan to improve django's ability to play nice with the wsgi
> > community with 2-way conversions between django views and wsgi apps,
> > and between django middleware and wsgi middleware.
>
> > I have started looking into the code needed to make this happen, and a
> > few things have creeped up that need some design decisions:
>
> > 1. view *args and **kwargs (django view -> wsgi app)
> > a wsgi app created from a django view is probably not going to be
> > called by django's dispatcher, so we have to either do without
> > arguments besides a request object, or generate them in the new wsgi
> > app. we could just say that django views are only eligible to become
> > wsgi apps if they take no extra arguments:
>
> > @view_to_wsgi_app
> > def django_style_view(request):
> > #...
>
> > but i think that takes considerable punch out of the proposal. maybe
> > if the decorator accepted a regular expression like in urlpatterns,
> > the decorator could pull the arguments out of the request path.
>
> > @view_to_wsgi_app(r'books/get/(?P<book_id>\d{2})/')
> > def django_style_view(request, book_id=None):
> > #...
>
> > and it could potentially also take *args and **kwargs to add to the
> > info pulled from the path
>
> > @view_to_wsgi_app(r'books/get/(?P<book_id>\d{2})/', 'James Joyce',
> > publisher='Penguin')
> > def django_style_view(request, author, book_id=None, publisher=None):
> > #...
>
> > with that we have pretty much the same control that we had with
> > django's urlpatterns routing, but potentially some duplicated work if
> > you are also defining these patterns with Routes or whatever else.
>
> > 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.
>
> > 3. error pages (views -> apps, dj middleware -> wsgi middleware)
> > i think when we take a django piece and stick it into a wsgi
> > environment, we should give up most control and only do the one
> > specific task. but then again our error pages sure are nice. maybe
> > this is an argument for pulling the error pages into exception
> > middleware which could then be converted to wsgi middleware.
>
> > travis parker
>
> How about creating Django Views from WSGI middleware(aka just hooking them
> up in the URLConf), this is probably a bit easier, maybe even just a wrapper
> function to assign an attr to it so the Handler knows to give it whatever
> the appropriate params are(I'm not totally up on what WSGI middleware looks
> like).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." --Voltaire
> "The people's good is the highest law."--Cicero
wsgi middleware doesn't necessarily expect to be the ending turnaround
point (django's views do - they *must* accept an HttpRequest and
*must* return an HttpResponse). the django version of wsgi middleware
is django middleware as they both might return a response or might
pass the request on down the stack (or on the other end, might modify
or replace the response coming up the stack from below).
i realized something else:
4. wsgi middleware -> django middleware is probably not possible
this is for the same reason that we don't have a
middleware_from_decorator utility. a piece of wsgi middleware is
simply a decorator around a wsgi application (which is a callable), so
the behavior of what to do when the decorated app throws an exception
is buried in the same fucntion as what to do with the request, and
what to do with the response. they can't be split up. we could
probably make a converter of wsgi middleware into django view
decorator.
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
-~----------~----~----~----~------~----~------~--~---
