#9081: [patch] More flexible render_to_response()
------------------------------------+---------------------------------------
Reporter: bhagany | Owner: ccahoon
Status: new | Milestone:
Component: HTTP handling | Version: 1.0
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
------------------------------------+---------------------------------------
Changes (by ccahoon):
* needs_better_patch: 0 => 1
* stage: Design decision needed => Accepted
Comment:
@bhagany: To start, I think you're right that we should overhaul the
shortcuts. I would like to help with it, and sorry I provided what seems
like kind of strong resistance. I imagine a lot of it came from code-smell
and the effects of trying to really minimize the changes I have been
making on my branch in hopes that I can get a lot of the work put into
trunk -- nothing unnecessary (at least when I remember). So now, to
sorting out how we want to go about improving this shortcut.
I see now why the route you took made sense, in the context of looking at
the other shortcuts, but there are two reasons why I continue to disagree
with the implementation:
1) Those two shortcuts you mentioned are a pretty different situation from
this one, because they essentially wrap the call so that we can 404 if it
doesn't work. And _get_queryset, which doesn't pass arguments, only exists
because the classes you would want to get a QuerySet from behave
differently. This shortcut (render_to_response), though, just does some
dirty work for us and maybe allows some customization.
2) There is an easier way of doing the same thing (which doesn't smell to
me). Take a look at #10588. It solves the same problem, but in a manner
that is more appropriate to how HttpResponse and its children work. The
different response classes, except for Redirect, NotAllowed, and SendFile
(on my branch), don't actually behave any differently except for the
status codes (which can be changed already through a kwarg). And those
three that I mentioned do not have need for template rendering. Passing
in a class is less direct than necessary.
So to improve this shortcut, I'd suggest that we perhaps allow it to
deliver all of the possible kwargs for an HttpResponse. Mimetype is
actually sort of deprecated -- it's really content-type that we want. So
say we allow content_type, status(code), and request (assuming my
charset/codec changes get merged with trunk). With your docs and the 10588
change and tests (with the additional kwargs), this would be a useful
change. Do you degree, since the other response classes that need
templates are essentially vestigial, that if people really need to use
them, they can deal with a context and template loader?
Especially now that the project is moving towards 1.2, I think a nice long
look at "overhauling," and hopefully augmenting the shortcuts, is a great
idea. Within that context, I think the change makes a lot of sense.
--
Ticket URL: <http://code.djangoproject.com/ticket/9081#comment:11>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
