Hi Davor,
On Tue, Jan 5, 2010 at 5:06 PM, rebus_ <[email protected]> wrote:
> Hi,
>
> This is the "natural" sequence of doing things anyway, i don't see why
> would you shuffle it around.
>
> 1. process stuff into variables
> 2. add said variables to a ContextRequest
> 3. send said ContextRequest to a template for rendering.
Nothing is shuffled around.
But we came to a bikeshed discussion.
> In the example buttman gave in his link [1] you could say you don't
> even need to specify a template. You could just have a decorator that
> says "this function is a view and when it returns take the name of the
> function and generate template name or even if it is ajax request
> append _ajax to template name". This is however even more implicit,
> though it could save you some typing.
>
> [1] http://github.com/nbv4/flightloggin/blob/master/logbook/views.py
>
>
>> 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.
>
> Personally I don't find this readable at all:
>
> @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'
>
> You explicitly set a template at the beginning of the view but few
> lines after it you mention yet another template.
> When someone is reading your code this could lead to confusion. What
> happens when you need to debug lets say few hundred line view? You
> could even forget that you used another template in it and pull your
> hair out why my/template.html doesn't produce wanted result.
Please, no imaginary arguments.
> Also, it doesn't either look or work much more different then:
>
> def my_view(request, param)
> template = 'my/template.html'
> if param == 'something':
> context = {'some':context}
> elif something_else():
> context = {'some_other':context}
> template = 'another/template.html'
> return render_to_response(template, context,
> context_instance=RequestContext(request))
Compare to:
@render_to()
def my_view(request, param)
template = 'my/template.html'
if param == 'something':
context = {'some':context}
elif something_else():
context = {'some_other':context}
template = 'another/template.html'
return context, template
render_to is made to translate
"return render_to_response(template, context,
context_instance=RequestContext(request))"
into "return context, template".
If you like the longer version, or don't see the difference, what else to talk?
In bikeshed question of what to use, render_to or render_to_response(),
the winner is clearly the smarter render shortcut, proposed in different thread.
"render(template, context, request)".
--
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.
