#9081: [patch] More flexible render_to_response()
---------------------------------------------+------------------------------
Reporter: bhagany | Owner: ccahoon
Status: new | Milestone:
Component: HTTP handling | Version: 1.0
Resolution: | Keywords:
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Comment (by bhagany):
@ccahoon - as far as it being confusing and code-smelly to pass in a class
and arguments, I refer you to get_object_or_404 and get_list_or_404, which
do pretty much this. render_to_response itself (well, really HttpResponse
and company, render_to_response by proxy) also allows something very close
to this with context_instance - you pass a context instance and what
actually goes into that context as separate arguments. I just took my cue
from the other shortcut functions that require this kind of flexibility.
As far as I can see, if this patch is wrong in this way, then most of the
existing shortcuts are also wrong.
> we have already had to use the class names and arguments we would need
to just instantiate a response. Doesn't it seem like we would be better
off creating the response anyway? It doesn't even seem like extra work...
With render_to_response, you don't have to mess with the template loader
or instantiate a Context. That's the work we're saving, and most of the
reason we use render_to_response in the first place.
> ... and that way we have the option to actually manipulate the response
before it gets returned
Why can't you do that with render_to_response? Just assign it to a var
instead of returning it directly.
> but I think it comes at the expense of the simplicity of the
render_to_response shortcut
I strongly disagree. People can continue to use render_to_response with
exactly the same amount of simplicity as they always have. It's a
completely transparent, fully backwards compatible change. Or are you
claiming that this patch itself is complex? I just don't see any
justification for this statement at all.
I don't think that this issue alone is worth bringing up on the
development list. However, I would like some clarification on what
direction the shortcuts module should be taken. I referenced a comment
from either Jacob or Adrian (memory fails me) above that I saw in the
DjangoCon vids last year, that shortcuts needs an overhaul. I have tried
to provide some very simple, useful extensions to a single shortcut, but I
have been met with either silence or a resistance that doesn't make sense
to me. Perhaps I misunderstood what I heard in the video? There seems to
be an overall sentiment on the development list that things don't get into
Django that people can do themselves, but this sentiment runs directly
contrary to the raison d'etre of having a shortcuts module at all. So, I
would like to know, specifically about the shortcuts module, are we going
to provide useful and flexible functionality, or are we going to tell
people that they can do it themselves? Because if it's the latter,
nothing will get into shortcuts ever again, and we shouldn't be saying
that it needs work. Shortcuts are the very definition of stuff you can do
yourself.
Most of this is not directed at you, Chris. The mixed signals are just
confusing and frustrating.
--
Ticket URL: <http://code.djangoproject.com/ticket/9081#comment:10>
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 django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
