render_to_response uses Context instead DjangoContext

[nesh <nesh [at] studioquattro [dot] co [dot] yu>]

As far as I can see render_to_response calls render_to_string which by default uses Context. Because of that all DjangoContext stuff (i.e. debug, user, ...) don't work.

I can use render_to_response(..., context_instance=DjangoContext()) but that is almost same as not using render_to_response altogether.

Maybe Context can be raplaced with DjangoContext in loader.py?

[nesh <nesh [at] studioquattro [dot] co [dot] yu>]

Update, correct usage is:

from django.core.extensions import render_to_response, DjangoContext

def index(request):
    return render_to_response('index', context_instance=DjangoContext(request, {}))
# index

At least documentation should be updated to state that render_to_response (and others) use Context instead DjangoContext.

[Adrian Holovaty]

My reasoning was that 80% of Django projects won't need the extra functionality of DjangoContext, so render_to_response() use the lowest common denominator.

[hugo]

Maybe a solution would be an optional request= parameter. If that is given, a DjangoContext(request) instance is created internally, if it is not given, the standard Context() is created?

[sean@…]

Perhaps we could have a configuration setting that allows usage of a custom context class in all of the generic views? Currently it is a bit of a mess if you want to use generic views in your project - sometimes you get a DjangoContext, sometimes Context (and no easy way to use a custom Context object). It would be nice to be able to say

CONTEXT_CLASS = "myproject.extensions.MyProjectContext"

I would also like to see things like _get_user moved out of the handlers (wsgi / etc) so that they are generic (this is less of an issue than the Context stuff since one can easily subclass the desired handler and implement their own user functionality) - not everyone (perhaps few) will use the generic User model that comes with Django. Could these things be moved out to contrib like the admin stuff recently was?

[Adrian Holovaty]

80% of Django projects won't need the extra functionality of DjangoContext, so render_to_response() uses the lowest common denominator.

[Christopher Lenz <cmlenz@…>]

I disagree with this. IIUC, only DjangoContext/RequestContext supports the TEMPLATE_CONTEXT_PROCESSORS, being used for credentials info, I18N, template debugging, etc, which I think are going to be used by way more than just 20% of Django projects.

I can understand that the base Context class makes sense to decouple the template engine from the request/response layer. However, the shortcut method is already called render_to_response() and returns an HttpResponse object, so it makes a ton of sense to me that it also accepts/expects an HttpRequest as input parameter and then uses a RequestContext.

render_to_resonse is nice, but having to import RequestContext and pass it in for every invocation is a pain.