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