> > I much prefer the @render_to() syntax. This way, I can think of my > > view functions as "context variable creators", instead of "response > > returners". I think of view functions as a sort of context processor > > thats only meant for one specific template. > > I'm in complete agreement with Simon on this point. I fail to see the > benefit of decorators in this context. However, it's easy to find > several negative points: > > * The "accept a request, return a response" view contract makes > sense, and is consistent with other layers in the Django stack. > * Special handling is required in the decorator when a view needs to > return HttpResponseRedirect (or any other non-template-rendered > response). This says nothing for the case where you need to return a > non-200 response *and* templated content.
I actually just checked one of my views, and the version of @render_to that comes with django-annoying does indeed let you return ResponseRedirect objects. For an example, look at this code: http://github.com/nbv4/flightloggin/blob/master/logbook/views.py which is currently in production and it works fine. If request.POST exists, it will save a form and then issue a ResponseRedirect, otherwise, it'll create some variables and then return locals(), which the decorator will then handle. > * The return value for views becomes a tuple with a convention, > rather than an explicit single (response) object. I don't understand this part. tuples? With the decorator views return dictionaries. > So - I'm fairly confident in saying that this isn't going to happen in > Django trunk. Fine with me. Either I import it from annoying.decorators or django.shortcuts, it don't make no difference to me... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
