Anonymous user
Boston Python Workshop/Saturday/Web app project: Difference between revisions
Boston Python Workshop/Saturday/Web app project (view source)
Revision as of 04:07, 15 October 2011
, 12 years agoRevert to pre-spam
imported>Paulproteus (Revert to pre-spam) |
|||
| (12 intermediate revisions by 8 users not shown) | |||
Line 626:
Does your detail view work? Try it: http://127.0.0.1:8000/polls/1/
You can also try to load a poll page that does not exist, just to test out the pretty 404 error: http://127.0.0.1:8000/polls/32/
=== Adding more detail ===
Line 645 ⟶ 647:
Method-calling happens in the {% for %} loop: poll.choice_set.all is interpreted as the Python code poll.choice_set.all(), which returns a sequence of Choice objects and is suitable for use in the {% for %} tag.
Load the new detail page in your browser: http://127.0.0.1:8000/polls/1/ The poll choices now appear.
=== Adding some style ===
Line 679 ⟶ 683:
* Since we're creating a POST form (which can have the effect of modifying data), we need to worry about Cross Site Request Forgeries. Thankfully, you don't have to worry too hard, because Django comes with a very easy-to-use system for protecting against it. In short, all POST forms that are targeted at internal URLs should use the {% csrf_token %} template tag.
The {% csrf_token %} tag requires information from the request object, which is not normally accessible from within the template context. To fix this, a small adjustment needs to be made to the detail view in the "views.py" file, so that it looks like the following:
<pre>
Line 690 ⟶ 694:
</pre>
The details of how this works are explained in the [http://docs.djangoproject.com/en/dev/ref/templates/api/#subclassing-context-requestcontext documentation for RequestContext].
Now, let's create a Django view that handles the submitted data and does something with it. Remember, in Tutorial 3, we created a URLconf for the polls application that includes this line:
| |||