Hi Davor, On Tue, Jan 5, 2010 at 5:06 PM, rebus_ <r.dav...@gmail.com> 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: bu...@live.com -- 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.