On Tue, Jan 5, 2010 at 1:57 AM, buttman <[email protected]> wrote: > On Jan 2, 5:52 pm, Simon Willison <[email protected]> wrote: >> On Dec 30 2009, 10:28 pm, Wim Feijen <[email protected]> wrote: >> >> > In the discussions on CSRF there have been several proposals to >> > include RequestContext by default in render_to_response or in a >> > similar function. As a side note to my previous post, I'd like to >> > mention my favorite way to do this: render_to , see: >> >> >http://www.djangosnippets.org/snippets/821/ >> >> So here's how that's supposed to work: >> >> @render_to('my/template.html') >> def my_view(request, param): >> return {'data': 'some_data'} >> >> I have to admit I don't understand the appeal of this syntax at all. >> How is it any better than this? : >> >> def my_view(request, param): >> return render('my/template.html', {'data': 'some_data'}) >> >> The decorator implementation is more complicated, makes debugging >> trickier (since decorators confuse stack traces and other debugging >> tools) and doesn't save any typing. What are the advantages? >> >> I'm a big fan of decorators for things like caching/memoization, but I >> don't understand why they provide any advantage for the above. I'm not >> a fan of the current @permalink decorator in Django for the same >> reason - if a decorator simply changes the syntax for how arguments >> are passed to a function, what's the point of using them? >> >> Cheers, >> >> Simon > > 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. * The return value for views becomes a tuple with a convention, rather than an explicit single (response) object. So - I'm fairly confident in saying that this isn't going to happen in Django trunk. However, this position doesn't prevent you from using this approach in your own code, so if you're a fan of using decorators in this way, feel free to do so. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
