Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#650 closed defect (wontfix)

render_to_response uses Context instead DjangoContext

Reported by: nesh <nesh [at] studioquattro [dot] co [dot] yu> Owned by: adrian
Component: Template system Version:
Severity: major Keywords:
Cc: cmlenz@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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

Change History (7)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 10 years ago by hugo

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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?

comment:4 Changed 10 years ago by 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?

comment:5 Changed 10 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

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

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by Christopher Lenz <cmlenz@…>

  • Cc cmlenz@… added
Note: See TracTickets for help on using tickets.
Back to Top