request object availability

[Joeboy]

Ok, I've banged on about this a bit on the lists and not had much response so I'm trying again here.

Suppose I want my django website to differ according to the user that's logged into it. Eg. I want it to say 'Hello Jane Doe', or only display certain bits if the user's logged in, or some such very common thing that relies on the request object. So I put something to that effect in my base.html, make sure the auth context processor is in effect, and all is groovy.

*Except* that that information will only be available to the template if every view in my project uses a RequestContext instead of a vanilla Context, so, I need to go through my projects and change them all. This makes a bit of a mockery of the idea of pluggable apps, unless there's some edict that says all reusable apps should use RequestContext. And that means lots of miscellaneous data floating about in all contexts.

Am I right in considering this to be a rather significant problem? Do the devs envisage doing anything about it, (maybe in all that spare time left over from their day jobs and merging a million SoC branches)? If not, how should I deal with it? Just use RequestContext everywhere and stop whingeing?

What I think I would like, btw, is the ability to set up context processors for individual templatetags. I don't know quite how much that would involve swimming against the tide of the django code, but it would seem to address the problem. I recognise that there's a lot going on in django atm, but it would make me happy to at least get some kind of response about this, especially as people are talking about setting up public app repositories on the list at the moment.

Cheers.

[James Bennett]

I guess I see this as a common-sense kind of thing: if you're going to rely on context processors, or plan to distribute your app to people who may rely on context processors, then use RequestContext in all your views. So I, personally, don't see this as "a rather significant problem"; YMMV.

For per-tag stuff, keep in mind that RequestContext takes an optional extra argument specifying extra processors to use only on that instance.

[Adrian Holovaty]

I'm closing this because it does not address a tangible problem. If you're interested in asking for people's opinions about this, please do bring it up on django-developers.

[herbert.poul@…]

Replying to ubernostrum:

I guess I see this as a common-sense kind of thing: if you're going to rely on context processors, or plan to distribute your app to people who may rely on context processors, then use RequestContext in all your views. So I, personally, don't see this as "a rather significant problem"; YMMV.

imho the problem is, that if you try to create an application with templatetags which should be pluggable into any django website, you currently can't rely on the fact that RequestContext is used everywhere (and therefore the HttpRequest is accessible in the template tags) because users of your templatetags would have to modify every view in their own apps (and propably also 3rd party apps) to use a RequestContext .. - That's all assumed applications and templatetags should be independent from each other and should be pluggable into any django website.

i think at least ​http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters should contain a note that a RequestContext should always be used ? - btw. this site states that django-user should be used for comments on the document.. so i also wrote it on the django-users group a few days ago: ​http://groups.google.com/group/django-users/browse_frm/thread/cb25d63536db475d