>From my experience some reusable apps require (in their documentation) that
specific context_processors are installed. I'm also -0 unless some decent
alternative exists and there's a convincing argument why they aren't a good
feature to have.
Cheers
On Sunday, 11 January 2015 14:33:44 UTC+11, Collin Anderson wrote:
>
> Hi All,
>
> Based on the early feedback, here's a scaled back proposal:
>
> 1. In the project_template settings.py for new projects:
> - Enable the request context processor
> - Keep the auth context processor
> - Remove the rest (you can always install them by hand).
> 2. Make the admin work without needing specific context_processors enabled.
>
> It sounds like context_processors as a feature are here to stay, but here
> are some alternatives anyway:
> - Request attributes added by a middleware, like request.cart for a store.
> These can also be used in views.
> - Assignment tags, like {% get_navigation as nav %}. I agree creating
> custom template tags is not fun.
>
> Reusable apps can't assume specific context_processors are installed and
> may need to use alternatives anyway.
>
> Collin
>
> On Saturday, January 10, 2015 at 6:42:21 PM UTC-5, Russell Keith-Magee
> wrote:
>>
>>
>> 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/29c33ec7-436a-4863-ae21-b7584f594f8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
