On Tue, Mar 31, 2009 at 3:22 PM, Travis Parker <travis.par...@gmail.com>wrote:
>
> 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're completely right, I seem to recall hearing someone discuss the idea
and must have translated it into something it clearly wasn't :/
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
