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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
