On Sun, Jan 11, 2015 at 6:40 AM, 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?
>
>
I feel like I've missed part of a discussion. We're talking about the
contents of TEMPLATE_CONTEXT_PROCESSORS, right? What exactly is the issue
with global context processors?
Speaking personally - I'm definitely using global context processors at the
moment, and it isn't clear to me what alternative you're proposing.
My use case - my site is multi-tenant, and on every request, I need to
exact who the tenant is, and a couple of important attributes of the user
in light of that tenancy. These attributes are all used in my site base
template, so it's not like they are only used on some views - they really
are used globally.
However, I think my use case ultimately isn't that much different to the
messages case. contrib.messages is an optional app; if you're using it,
then you're probably going to have a place in your base template where you
want to display those messages. Making every view manually define that they
want to have messages available sounds extremely onerous; it would be
trivial to accidentally forget to add messages handling to a view, and site
behavior would be dramatically impacted.
At a conceptual level, I have no problem with the idea that there may be a
collection of context variables that need to be applied to *every* view -
or, at the very least, a significant subset of pages. I can see how you
might couple reworked context processors and middleware into a reworked
hierarchical URL structure (so a URL subtree has a particular set of
context processors and middlewares; subtrees of that subtree inherit those
augmentations; by default, there's only one URL subtree, so context
processors and middlewares are global).
So, unless there's a particularly compelling technical reason that I'm
missing, or an equally "global" alternative being proposed, I'm -1 to
removing TEMPLATE_CONTEXT_PROCESSORS.
Yours,
Russ Magee %-)
--
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/CAJxq848qf2F7bHn9MiC49AiVQAhYUzE%3DpJdu8L18i%2B8shM8tsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
