Hi Simon,
Readability is all about lots of tiny details.
I suppose you meant this:
def my_view(request, param):
return render('my/template.html', {'data': 'some_data'}, request)
This decorator intercepts `request` argument.
When you have 2 or more ways to return anything from function, it
looks much better.
Moreover, visually it looks much better too: this important
information of what page is rendered to each template is always right
here.
@render_to('my/template.html')
def my_view(request, param):
if param == 'something':
return {'data': 'some_data'}
elif something_else():
return HttpResponse('not found anything at all')
else:
return {'data': 'some_other_data'}, 'another/template.html'
What both render_to decorator and render() still miss, is extendability.
I think, Django still misses a lot when it comes to views/templates
extensibility.
Look at 3rd-party apps or django contribs. You can freely use their
models, but 90% of cases you can't reuse their views.
def your_view(request, param):
if param == 'something2':
return login(request, template='login.html') +
{'additional_key':'additional_value'} # how do I do this?!
else:
return my_view(request, param, template='your/template.html')
+ {'additional_key':'additional_value'} # or how do I do this?
How to make these lines of code effective and readable at all?
Some views don't provide template= option, some call it differently...
You are now only able to add middleware to extend already generated
HttpResponses.
I think, RequestContext was made to make such extendability more
simple, but it was (almost?) never used in that way.
We had discussion both about this issue and
render_to/render/render_to_response already in django-developers.
http://groups.google.com/group/django-developers/browse_frm/thread/f53fea4a0551ab7c/64956c854776f4e8
Still not found excellent solution.
On Sun, Jan 3, 2010 at 4:52 AM, 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
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [email protected]
--
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.
