On Mon, 19 Oct 2009 17:20:10 +0800 Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> > On Mon, Oct 19, 2009 at 4:47 PM, Exe <reg...@messir.net> wrote: > > > > Hello! > > > >> As a consequence of the proposed CSRF changes, we brought up > >> wanting to add a shortcut like render_to_response that uses > >> RequestContext > > > > I want to propose another method. > > > > Why we need RequestContext? We need it to provide global template > > variables. > > > > Why this is a bad idea? It's bad because when you are use foreign > > code and that code doesn't use RequestContext in it's view you can't > > provide global variables to templates(like 'user' and so). > > If you have a third-party project that you want to use that uses > Context instead of RequestContext, then you need to do one of the > following: > > 1) You need to understand why the developer chose to *not* include > request level data. There are some legitimate reasons to leave this > data out. > 2) You need to bug the developer to use RequestContext by default > for the view 3) You need to bug the developer to make the context a > configurable option (much in the same way that render_to_template > makes the Context class a configuration option). Please look at another side. I think possibility of adding own template variables is a core feature. Why we must think about it in any view? It's just inconvenient. I can't find a real case where using a TEMPLATE_CONTEXT_PROCESSORS by default will break a code. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
