#650 closed defect (wontfix)
render_to_response uses Context instead DjangoContext
Reported by: | nesh <nesh [at] studioquattro [dot] co [dot] yu> | Owned by: | Adrian Holovaty |
---|---|---|---|
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: | no | UI/UX: | no |
Description
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?
Change History (7)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
Resolution: | → wontfix |
---|---|
Status: | new → 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 by , 19 years ago
Resolution: | wontfix |
---|---|
Status: | closed → 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 by , 19 years ago
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 by , 19 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
80% of Django projects won't need the extra functionality of DjangoContext, so render_to_response() uses the lowest common denominator.
comment:6 by , 19 years ago
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 by , 19 years ago
Cc: | added |
---|
Update, correct usage is:
At least documentation should be updated to state that render_to_response (and others) use Context instead DjangoContext.