-
Notifications
You must be signed in to change notification settings - Fork 31
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
10 changed files
with
376 additions
and
86 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
*.log | ||
*.pyc | ||
*~ | ||
*build/ | ||
*build/doctrees/ | ||
*.db |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,27 +1,121 @@ | ||
Chapter 4. Building a Blog | ||
---------------------------- | ||
(Topics introduced: Authentication, Session management, NewForms, Generating simple RSS feeds. Date based generic views.) | ||
|
||
Diving in. [Code listing] | ||
|
||
Authentication. [In chapter 2, all views were managed by Admin, so we did not need to handle authentication. In chapter 3, all views would be public, so no authentication was needed. In this chapter we need to restrict access to only logged in user, so we introduce it here.] | ||
Using django.contrib.auth | ||
Using login_required decorator to restrict access to logged in users. | ||
Using request.user in views, for finer control over views. | ||
Using context processors to use logged in users in templates. | ||
|
||
Session Management. [So once user has commented, their name/email information is stored.] | ||
The machinery behind sessions framework. | ||
Using cookies. | ||
Using session to abstract handling cookies. | ||
|
||
Newforms. [Comment, Post, Settings form] | ||
Using newforms. | ||
Using model form to auto generate forms for model. | ||
Creating complex forms programatically. (Instead of defining them.) | ||
|
||
Generating RSS feeds. | ||
Using django.contrib.syndication to generate feeds for the Blog. | ||
|
||
Using date based generic views to generate monthly and weekly archives for the blog. | ||
.. | ||
(Topics introduced: Authentication, Session management, NewForms, Generating simple RSS feeds. Date based generic views.) | ||
|
||
Diving in. [Code listing] | ||
|
||
Authentication. [In chapter 2, all views were managed by Admin, so we did not need to handle authentication. In chapter 3, all views would be public, so no authentication was needed. In this chapter we need to restrict access to only logged in user, so we introduce it here.] | ||
Using django.contrib.auth | ||
Using login_required decorator to restrict access to logged in users. | ||
Using request.user in views, for finer control over views. | ||
Using context processors to use logged in users in templates. | ||
|
||
Session Management. [So once user has commented, their name/email information is stored.] | ||
The machinery behind sessions framework. | ||
Using cookies. | ||
Using session to abstract handling cookies. | ||
|
||
Newforms. [Comment, Post, Settings form] | ||
Using newforms. | ||
Using model form to auto generate forms for model. | ||
Creating complex forms programatically. (Instead of defining them.) | ||
|
||
Generating RSS feeds. | ||
Using django.contrib.syndication to generate feeds for the Blog. | ||
|
||
Using date based generic views to generate monthly and weekly archives for the blog. | ||
|
||
Topics in this chapter: | ||
======================= | ||
|
||
So far, we have seen how to use django's admin interface, and generic views. In this chapter we | ||
will write our own admin page for creating a blog entry, store some user details in the session | ||
and use date based generic views for our blog archives. | ||
|
||
|
||
Our blog app: | ||
============= | ||
|
||
Let's list out the features we would want to see in our blog: | ||
|
||
* Create/Edit blog post (restricted to admin) | ||
|
||
* View blog post (public) | ||
|
||
* Comment on a blog post (anonymous) | ||
|
||
* Store anonymous user details in session | ||
|
||
* Show month based blog archives | ||
|
||
* Generate RSS feeds | ||
|
||
We have two models here: ``Post`` and ``Comment``. The data we would like store are: | ||
|
||
For Post: | ||
|
||
* Title | ||
|
||
* Text Content | ||
|
||
* Slug | ||
|
||
* Created Date | ||
|
||
* Author | ||
|
||
For Comment: | ||
|
||
* Name | ||
|
||
* Website | ||
|
||
|
||
* Text Content | ||
|
||
* Post related to this comment | ||
|
||
* Created Date | ||
|
||
.. note:: | ||
Since we want anonymous to be able to comment on a post, we are not relating the comment poster | ||
to a registered user. | ||
|
||
We want the ``author`` field of the post to be mapped to a registered user and the ``post`` field | ||
to be mapped to a valid ``Post``. As we shall see, we will ForeignKeys to the appropriate models | ||
to manage these. | ||
|
||
We have already seen how to create and integrate an app into our project, so I will start with the models | ||
|
||
.. literalinclude:: djen_project/blog/models.py | ||
:language: python | ||
:commit: c95309c1e2951c54bd25 | ||
|
||
Quite a few new things here, let's analyze them: | ||
|
||
* slug field - it is used for storing slugs (e.g. this-is-a-slug). SEO or something. | ||
|
||
* We will be using slugs in the url to fetch a blog post, so this must be unique. | ||
|
||
* ``slugify`` is a helper function to get slug from a string. We won't need to get the slug from the form, | ||
we will generate it ourself using ``slugify`` | ||
|
||
* To autogenerate the slug, we override the ``model`` save method, whose signature is ``save(self, *args, **kwargs)`` | ||
We set ``self.slug`` to the slug generated by ``slugify`` and call the parent ``save`` method. | ||
|
||
* This ensures that every time a model is saved, it will have a slug field. | ||
|
||
* The ``get_absolute_url`` of the ``Post`` model points to the ``blog_post_detail`` which takes a ``slug`` parameter. | ||
This is the ``Post`` detail view, and it fetches the post based on the ``slug``. We will soon see how this is implemented. | ||
|
||
* ``model.ForeignKey`` is a ForeignKey field which can be used to link this model to any other model. Here we want to link the ``author`` | ||
field to a ``User``, which is django's model for a user. It comes from ``django.contrib.auth`` app, which is another useful package | ||
shipped with django. | ||
|
||
* Similarly to link a ``Comment`` to a ``Post`` we have a ForeignKey from in the ``post`` field of the comment. | ||
|
||
* We won't need the ``author`` field from the ``Post`` form either, but we will fill it up in the view, where we have access to the | ||
logged in user details | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.