On 12/31/05, Michael Hipp <[EMAIL PROTECTED]> wrote:
> Who/what is the caller?
Whatever method calls 'HttpResponse()'. In this case, the view.
> It's not that I have something against render_to_response, it's that all the
> tutorials and docs seem to be saying that the "correct" way is HttpResponse
> and my objective is to be consistent with the published materials. (Failing
> that, I'd like to understand why the app I'm trying to build requires a
> different approach than seemingly everything else.)
In this case, I think the Django tutorial takes the approach of
teaching you how to do basic math yourself before teaching you how to
use a calculator ;) You'll notice that in that tutorial,
render_to_response() is mentioned as a shortcut; the tutorial still
uses the more cumbersome method, but you certainly don't have to --
the shortcut, I hope, is provided for a reason, so that once you
understand the idea of loading a template, instantiating a context and
rendering it, you can do it all from one line of code instead of doing
it all manually every time.
> So is there an error in the tutorials in that HttpResponse won't, in fact,
> cause that string to appear on the screen? If it will do that, then what is
> required to make it happen?
It will. Again, the difference is in what you tell HttpResponse to do.
If you just hand it a string, then you get that string on the
displayed page and nothing else. If, on the other hand, you want to
use a template and populate it with variables, you need to do the
template loading, instantiate a context, etc., or use
render_to_response() to do the heavy lifting for you.
> Ok, that's beginning to sink in somewhat. But in the tutorial example
>
> (myproject/apps/polls/views.py)
> def index(request):
> return HttpResponse("Hello, world. You're at the poll index.")
>
> what variable receives the "Hello, world" string?
No variable. You're literally saying to Django, "Print this message
and nothing else." If you wanted to, you could have your view code
build up all the HTML tags that make up a page, fill in the
appropriate content, and then collapse it all into a string you'd pass
to HttpResponse, but that'd be incredibly cumbersome, and the template
system lets you avoid having to do that. Here's a simple example, a
page that just prints out a personalized message from a username
(assume you get the username from somewhere else, and it's passed as
an argument to the view):
def hello(request, username):
message = "<html><head><title>Hello,
%s</title></head><body><p>Hello, %s</p></body></html>" % (username,
username)
return HttpResponse(message)
This would take the username, drop it into the HTML, and return the
response. But it's a bit cumbersome, and if you had multiple
variables, or wanted to, say, return one page if the username is 'Bob'
and another if it's anyone else, it quickly becomes very nasty.
With Django's template system, however, you could write a template,
say we'll call it 'hello.html':
<html>
<head>
<title>Hello, {{ username }}</title>
</head>
<body>
<p>Hello, {{ username }}</p>
</body>
</html>
And corresponding view:
def hello(request, username):
t = loader.get_template('hello')
c = Context({'username' : username})
return HttpResponse(t.render(c))
This would accomplish the same thing and, once you're doing anything
remotely complicated in your pages (multiple variables, for loops,
etc.), it's much, much easier.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
