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