I like it from a purity point of view, but I'm dreading updating through it
and replacing every instance of `{{ STATIC_URL }}` in my templates...I also have a number of small projects which add a custom context processor which add a certain queryset into the context every time because they form a part of the page navigational architecture. I don't really want to have to do this either 1) in every view or 2) via a custom template tag (because I hate custom template tags). A similar example would be the `add_page_if_missing`[1] context processor provided by feinCMS - it adds the best matching CMS page to every view's context so your custom views don't have to load the page themselves every time. So I'm maybe +0 on the changes suggests, but I'm -0 on removing the whole concept of context processors, at least without a suitable "one hit" way of getting certain variables into the context of (nearly) every page. Marc [1] http://www.feinheit.ch/media/labs/feincms/api/contextprocessors.html On 10 January 2015 at 22:40, Collin Anderson <[email protected]> wrote: > Hi All, > > In talking to Aymeric and other developers, we're starting to think about > the usefulness of global template context_processors. It seems to us that > ideally you should only need the "request" context processor. You could > even imagine removing context_processors all together and having render() > and class based views simply put the request in the context. > > Some ways to avoid context processors: > {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless) > {{ mediafile.url }} instead of {{ MEDIA_URL }} > {{ request.user }} instead of {{ user }} > {% get_current_timezone as TIME_ZONE %} > {% get_current_language as LANGUAGE_CODE %} > > I propose: > > - Enabling the request context processor for new projects. > - Modifying the admin to work without context processors. > https://code.djangoproject.com/ticket/24117 > - Removing the other context processors for new projects. (Possibly > waiting for 1.9). > - Possibly adding `request.messages` similar to `request.user`. > - Maybe adding `user.perms` or a template tag to replace {{ perms }} > > This would be a somewhat controversial change. I think django originally > tried hard to keep the request as separate from the response as possible. > This would tie the two together even more. In my experience working with > django projects, it's often very helpful to have the request object > directly available in templates. > > What do you think? > > Collin > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/bf74b593-3fbb-46fe-89f6-ce280124d707%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/bf74b593-3fbb-46fe-89f6-ce280124d707%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Gx29ztS9xA-cA3Pn2H9U4P6JjwPxo7fx1qqY8EBkd_Jw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
