Django速成：构建一个Blog-CSDN博客

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE Django速成：构建一个Blog

Django自称是“最适合开发有限期的完美Web框架”。所以现在我们来挑战一下，看看到底能在多短的时间里用Django完成一个简单的blog。（关于追求完美的部分我们稍后再细说。）

注意

本章假设你已经安装了Django。如果还没有的话，请参见附录B。

本章所有工作都是在你选择的shell（bash、tcsh、zsh和Cygwin等）下以命令行方式完成。所以，首先打开终端，键入cd命令进入你PYTHONPATH环境变量所指向的目录。在Linux、Mac OS X、FreeBSD等类UNIX的系统上，你可以用echo $PYTHONPATH命令来查看其内容。在Win32的命令行窗口里，则可以输入echo %PYTHONPATH%。你可以在第1章里读到更多关于路径和安装的内容。

我们建议你在阅读的同时实际动手构建这个blog。如果做不到（例如不在电脑旁边，或者没这个耐性）的话，简单读一下本章也是好的。特别是如果你有其他现代Web框架开发的经验就更好了，因为很多基本的概念都是相似的。

如果你确实打算在电脑上实际操作，同时遇到和你在这里看到的结果不同的情况时，请停下来重新检验刚才的步骤，然后复查之前的两到三步。看看是不是有哪些看上去不重要的地方，或是哪些不能理解的步骤被遗漏掉了。如果还是没发现哪里不对，那就删掉整个项目重新来过。作者在学习Django时就用过这个办法；这样比无助地盯着错误信息看上几个小时要有效率，而且重复那些会导致错误的步骤还能帮你加深印象！

2.1 创建项目

组织Django代码最简单的方式是使用Django的“项目”（project）：一个包含了组成单个网站的所有文件的目录。Django提供了一个叫django-admin.py的命令来帮助创建这样项目的目录。在UNIX上，它的默认安装路径为/usr/bin；在Win32上，它的位置是Python安装目录下的Scripts文件夹，比如C:\Python25\Scripts。无论是哪一个平台，你都要保证django-admin.py在PATH环境变量里以保证它可以从命令行执行。

为blog项目创建一个项目目录的django-admin.py命令是：

在Windows上，你需要先打开一个DOS命令窗口。可以通过【开始→程序→附件→命令提示符】来启动这个窗口。另外，你会看到C:\WINDOWS\system32这样的提示符，而不是$符号。

现在我们来看看这个命令为你创建的目录里有点什么内容。在UNIX上它看起来是这样的：

如果你是在Win32平台上进行开发，那么打开资源管理器窗口你可以看到图2.1这样的文件夹，这里我们所创建的目录是C:\py\django，项目的内容将会存放在这里。

图2.1 Win32上的mysite文件夹

注意

如果你精通Python的话，你一定知道__init__.py会把这个项目目录变成一个Python的包（package）—相关Python模块的一个集合。这让我们可以用Python的“点记号”（dot-notation）来指定项目中的某个部分，比如mysite.urls。（你可以阅读第1章，以获取更多关于包的内容。）

除了__init__.py，startproject命令还创建了以下三个文件：

?manage.py文件是一个同这个Django项目一起工作的工具。你可以从它在目录列表中的权限里看到它是可以执行的。我们马上就会用到它。

?settings.py文件包含了项目的默认设置。包括数据库信息、调试标志以及其他一些重要的变量。你项目里安装的任何应用都可以访问这个文件。稍后在本章进行过程中我们会展示其更多的作用。

?urls.py文件在Django里叫URLconf，它是一个将URL模式映射到你应用程序上的配置文件。URLconf是Django里非常强大的一个特性。

注意

startproject命令创建的所有文件都是Python的源码文件。这里没有XML、.ini文件，或是任何时髦的配置语法。Django追求的是尽可能地保持“纯Python”这一理念。这让你在拥有诸多灵活性的同时无需在框架里引入任何复杂性。例如，如果你想让你的settings文件从其他文件导入设置，或是计算一个值而避免硬编码的话都可以畅行无阻—因为它就是Python而已。

2.2 运行开发服务器

到这里，你还没有构建完blog应用，不过Django为你提供了一些可以就地使用的方便。其中最好用的就是Django的内置Web服务器了。这个服务器不是用来部署公共站点，而是用来做快速开发的。其优点在于：

?不需要安装Apache、Lighttpd，或是其他任何实际生产所需的Web服务器软件—如果你在一台新的服务器或是没有服务器环境的开发机上，或是就想实验一下的话，那就非常方便了。

?它会自动检测到你对Python源码的修改并且重新加载那些模块。相比每次修改代码后都要手动地重启Web服务器可是大大地节约了不少时间，这对绝大多数Python的Web服务器设置来说都是很有必要的。

?它知道如何为admin应用程序寻找并显示静态的媒体文件，所以你就可以直接使用它。

运行开发服务器（或“dev”）简单到只需要一个命令就行了。这里我们要用到项目里的manage.py工具，这是一个简单的包裹脚本，能直接告诉django-admin.py去读入项目特定的settings文件。启动dev的命令如下：

在Win32平台你应该能看到类似如下的输出，只是要退出时要按下的快捷键是Ctrl+Break而不是Ctrl+C。

在浏览器里输入这个链接，你会看到Django的“It worked!”页面，如图2.2所示。

同时，如果你查看终端的话，你会看到dev服务器记录下了你的GET请求。

log从左到右有4个部分：时间戳、请求、HTTP状态码，以及字节数。（你看到的字节数或许会有所不同。）这里状态码404（“Not Found”）是因为还没有为项目定义任何URL。而“It worked!”页面只是Django委婉地告诉你这一点的方式。

提示

如果服务器不工作的话，请重新检查每一个步骤。不要怕麻烦！有时候直接删掉整个项目，然后重新开始可能反而比劳心劳力地检查每一个文件，每一行代码要来的简单。

如果你成功启动服务器后，我们就可以来设置你的第一个Django应用了。

2.3 创建Blog应用

有了项目以后，就可以在它下面创建应用（按Django的说法是“app”）了。我们再次使用manage.py来创建这个blog app。

这样就完成项目的创建了。现在我们在项目的目录下有了一个blog目录。这是它的内容，首先是UNIX下的，接着是Windows资源管理器里的截图（图2.3）。

图2.3 Win32上的mysite\blog文件夹

和项目一样，app也是一个包。现在models.py和views.py里还没有真正的代码，它们只是先占住位子而已。实际上对我们这个简单的blog来说，我们根本用不着views.py文件。

要告诉Django这个app是项目里的一部分，你需要去编辑settings.py文件（也称之为“配置文件”）。打开配置文件并在文件尾部找到INSTALLED_APPS元组。把你的app以模块的形式添加到元组里，就像这样（注意结尾的逗号）：

Django用INSTALLED_APPS来决定系统里不同部分的配置，包括自动化的admin应用以及测试框架。

2.4 设计你的Model

现在我们来到了这个基于Django的blog应用的核心部分：models.py文件。这是我们定义blog数据结构的地方。根据DRY原则，Django会尽量利用你提供给应用程序的model信息。我们先来创建一个基本的model，看看Django用这个信息为我们做了点什么。

用你最习惯的编辑器（如果它能支持Python模式就最好）打开models.py文件。你会看到这样的占位文本：

删掉注释，加入下列代码：

这是一个完整的model，代表了一个有3个变量的“BlogPost”对象。（严格说来应该有4个，Django会默认为每个model自动加上一个自增的、唯一的id变量。）

这个新建的BlogPost类是django.db.models.Model的一个子类。这是Django为数据model准备的标准基类，它是Django强大的对象关系映射（ORM）系统的核心。此外，每一个变量都和普通的类属性一样被定义为一个特定变量类（field class）的实例。这些变量类也是在django.db.models里定义，它们的种类非常多，从BooleanField到XMLField应有尽有，可不止这里看到的区区三个。

2.5 设置数据库

如果你没有安装运行数据库服务器的话，我们推荐使用SQLite，这是最快最简单的办法。它的速度很快，被广泛接受，并且将它的数据库作为一个文件存放在文件系统上。访问控制就是简单的文件权限。更多关于在Django里使用数据库的信息请参阅附录B。

如果你安装了数据库服务器（PostgreSQL、MySQL、Oracle和MSSQL），并且希望用它们而非SQLite的话，你需要用相应的数据库管理工具为Django项目创建一个新的数据库。在这里我们把数据库取名为“djangodb”，不过你可以选用任何喜欢的名字。

当你有了一个（空的）数据库以后，接下来只需要告诉Django如何使用它即可。这就需要用到项目的settings.py文件。

使用数据库服务器

很多人都选用PostgreSQL或MySQL这样的关系数据库和Django配合使用。这里有6个相关的设置（虽然你可能只要两个就够了）：DATABASE_ENGINE、DATABASE_NAME、DATABASE_HOST、DATABASE_PORT、DATABASE_USER和DATABASE_PASSWORD。它们的作用从名字上就能看的出来。你只需在相应的位置填入正确的值就可以了。例如，为MySQL的设定看上去是这样的：

注意

我们没有指定DATABASE_PORT是因为只有当你的数据库服务器运行在非标准的端口上时才需要那么做。比如，MySQL服务器的默认端口为3306。除非你修改了这个设置，否则根本不用指定DATABASE_PORT。

要知道创建新数据库和（数据库服务器要求的）数据库用户的细节，请参阅附录B。

使用SQLite

SQLite非常适合测试，甚至可以部署在没有大量并发写入的情况下。因为SQLite使用本地文件系统作为存储介质并且用原生的文件系统权限来做访问控制，像主机、端口、用户或密码这种信息一律统统不需要。因此Django只要知道以下的两个设置就能使用你的SQLite数据库了。

注意

当SQLite配合Apache这样真正的Web服务器一起使用时，你需要确认拥有Web服务器进程的账号也拥有对数据库文件以及包含数据库文件目录的写权限。在我们这里用dev服务器做开发的情况下，这通常不是一个问题，因为运行dev服务器的用户（你）同时也拥有项目的文件和目录。

SQLite在Win32平台上也是非常受欢迎的选择之一，因为它是随同Python一同免费发布的。假设我们已经为项目（和应用程序）创建了C:\py\django目录，现在再来创建一个db目录。

如果你不太熟悉Python的话，你会注意到这个例子和前一个例子的不同之处，之前我们在sqlite3上用的是双引号，而在Win32的版本里，我们用的是单引号。这个和平台是没有关系的—Python没有字符类型，所以单引号和双引号都是被等同对待。只要保证你用同样的引号引用字符串就可以了！

你还应该注意到了文件夹名字前的小写“r”。如果你没有读过第一章，那么你应该知道它的意思是这个对象是一个raw字符串，或者说它把字符串里所有字符都逐字保留下来，不对任何特殊字符组合做转义。例如，\n通常代表一个新行，但是在raw字符串里，它（字面上）代表了两个字符：一个反斜杠和一个小写n。所以raw字符串的作用（特别是对这里的DOS文件路径来说）就是告诉Python不要转义任何特殊字符（如果有的话）。

创建表

现在你可以告诉Django用你提供的连接信息去连接数据库并且设置应用程序所需的表。命令很简单：

在Django设置数据库的过程中你会看到类似这样的输出：

当你执行syncdb命令时，Django会查找INSTALLED_APPS里的每一个models.py文件，并为找到的每一个model都创建一张数据库表。（在稍后我们碰到华丽的多对多关系时会有例外，但是对这个例子来说是正确的。如果你用的是SQLite，你还可以看到django.db数据库会在你指定的位置上被创建出来。）

INSTALLED_APPS里的其他默认条目也都拥有model。manage.py syncdb的输出就确认了这一点，你可以看到Django为每个app都创建了一个或多个表。

但这还不是syncdb命令输出的全部。你还会被问到一些和django.contrib.auth app有关的问题。

现在你在auth系统里建立了一个超级用户（就是你自己）。这在等一会我们加入Django的自动admin应用时就会变得很方便。

最后，这一过程还包裹了一些和特性fixture有关的代码，在第4章里我们在讨论这个。这让你在一个新建立的应用里预先载入数据。我们在这里没有用到这个特性，所以Django会跳过它。

到此数据库的初始化就完成了，下次你再对这个项目运行syncdb命令（只要你添加了应用或是model时就要执行）时，就不会再看到那么多输出了，因为它不需要再次设置表或者提示你创建超级用户了。

2.6 设置自动admin应用

自动化的后台应用程序admin称得上是Django“皇冠上的明珠”。任何对为Web应用创建简单的“CRUD”（Create，Read，Update，Delete）接口感到厌倦的人来说，这绝对是喜从天降。我们会在第11.1节里深入讨论admin。现在我们只要拿来直接用就好了。

由于这不是Django的必要组件，你必须在settings.py文件里指定你要使用它—就和指定blog app一样。打开settings.py并在INSTALLED_APPS元组里的'django.contrib.auth'下面添加这样一行。

每次往项目里添加新的应用后，你都要运行一下syncdb命令确保它所需的表已经在数据库里创建了。在这里可以看到在INSTALLED_APPS里添加admin app并运行syncdb命令会往我们的数据库里加入一个新的表：

设置完app以后，我们需要为它指定一个URL这样才能访问它。你应该已经注意到了在自动生成的urls.py中的这样两行代码。

删掉第二行开头的#号（也可以同时删掉第一行）并保存文件。这样你就告诉Django去加载默认的admin站点，这是被用于contrib admin应用程序的一个特殊对象。

最后，你的应用程序需要告诉Django要在admin窗口里显示哪一个model以供编辑。要做到这一点很简单，只要定义之前提到的默认admin站点，并向其注册BlogPost model就行了。打开mysite/blog/models.py文件，确认导入了admin应用，然后在最后加上一行注册model的代码。

这里admin的简单使用只不过是冰山一角，它还可以通过为给定model建立一个特殊的Admin类来指定许多不同和admin有关的选项，然后向那个类注册model。这个我们稍后再说，在后面的章节里你还会看到admin的高级使用，特别是本书第三部分和第四部分。

2.7 试用admin

到这里我们已经在Django里设置了admin app并向其注册了model，现在是时候试一试它了。再次运行manage.py runserver命令，随后在浏览器里输入http://127.0.0.1:8000/admin/。（你的dev服务器可能不是这个地址，没关系，只要在后面加上admin/就可以了。）你应该会看到一个登录窗口，如图2.4所示。

输入你之前创建的“超级用户”名字和密码。登录后，你就可以看到admin的主页了，如图2.5所示。

图2.4 admin登录页面

图2.5 admin主页

本书稍后会解释这个界面，现在只需确认你的应用程序Blog和截图里一样出现在屏幕上。如果没有的话，请重新检查之前的步骤。

提示

三个最常见的“我的app没有显示在admin里”的原因是：

1）忘记向admin.site.register注册你的model类；

2）models.py里有错误；以及

3）忘记在settings.py中的INSTALLED_ APPS里添加app。

有没有内容的blog么？点击Blog Posts右侧的Add按钮。Admin会显示一个表单让你添加新的帖子，如图2.6所示。

图2.6 通过admin添加新内容

给你的帖子取一个名字然后往里填一点内容。至于时间戳，你可以点击Today和Now的快捷链接来获取当前的日期和时间。你还可以点击日历或时钟标志来方便地选择时间。

完成之后，点击Save按钮保存。你会收到一条确认消息（“The blog post 'BlogPost object' was added successfully.”）和一个列出你所有blog帖子的列表—目前只有一篇而已，如图2.7所示。

为什么帖子有“BlogPost object”这么难看的名字？Django的设计是希望能灵活地处理任意类型的内容，所以它不会去猜测对于给定的内容什么变量才是最合适的。在第三部分的例子里，你会看到如何为你对象的默认标签指定一个特定变量，或是特别定制的字符串。

现在点击右上角的“Add Blog Post +”按钮添加另一篇不同内容的帖子。当你回到列表视图里，你会看见页面上加入了另一个BlogPost。如果你刷新页面或是离开应用程序再回来的话，输出不会有任何变化—你一定不会喜欢看见所有条目都被标为“BlogPost object”，如图2.8所示。你不是第一个这么想的人，“总有办法让它看起来顺眼一点吧。”

图2.7 成功地保存你的第一篇blog

图2.8 不太有用的小节页面

不过我们不需要等到那个时候来清理admin视图里的这些列表显示。之前我们通过很少的配置就激活了admin工具，即向admin app注册我们的model。现在只要额外的两行代码以及对注册调用的一些修改，我们就可以让列表看起来更漂亮更有用。更新你的mysite/blog/models. py文件，添加一个BlogPostAdmin类，并将它加到注册代码那一行里，于是现在models.py看起来是这样的：

开发服务器会注意到你的修改并自动重新加载model文件。如果你去看一下命令行shell，就能看到这些效果。

刷新一下页面，现在你就可以看到一个更有意义的页面了，它是根据你添加到BlogPostAdmin类里list_display变量来生成输出的，如图2.9所示。

图2.9 这样就好多了

试着点一下Title和Timestamp列的标题—每一个都影响了你的条目是如何排序的。例如，点一下Title会按照升序排列标题，再点一下则变成降序排列。

Admin还有很多有用的特性只需一到两行代码就可以激活：搜索、自定义排序、过滤等。就像我们多次提到的，在本书第三和第四部分里会更详细地展示这些内容。

2.8 建立Blog的公共部分

完成我们应用的数据库部分和admin部分后，现在来看看面向公众的页面部分。从Django的角度来说，一个页面具有三个典型的组件：

?一个模板（template），模板负责将传递进来的信息显示出来（用一种类似Python字典的对象Context）。

?一个视图（view）函数，它负责获取要显示的信息，通常都是从数据库里取得。

?一个URL模式，它用来把收到的请求和你的视图函数匹配，有时也会向视图传递一些参数。

创建模板

Django的模板语言相当简单，我们直接来看代码。这是一个简单的显示单个blog帖子的模板：

它就是一个HTML（虽然Django模板可以用于任何形式的输出）加上一些大括号里的特殊模板标签。这些是变量标签（variable tag），用于显示传递给模板的数据。在变量标签里，你可以用Python风格的dotted-notation（点记号）来访问传递给模板的对象的属性。例如，这里假设你传递了一个叫“post”的BlogPost对象。这三行模板代码分别从BlogPost对象的title、timestamp和body变量里获取了相应的值。

现在我们稍微改进一下这个模板，通过Django的for模板标签让它能显示多篇blog帖子。

原来的3行没有动，我们只是简单地增加了一个叫做for的块标签（block tag），用它将模板渲染到序列中的每个元素上。其语法和Python的循环语法是一致的。注意和变量标签不同，块标签是包含在{% ... %}里的。

把这5行模板代码保存到文件archive.html里，然后把文件放到你的blog app目录里的templates目录下。这个文件的路径即为：

模板本身的名字是随意取的（叫它foo.html也没问题），但是templates目录的名字则是强制的。Django在默认情况下会在搜索模板时逐个查看你安装的应用程序下的每一个templates目录。

创建一个视图函数

现在我们来编写一个从数据库读取所有blog帖子的视图函数，并用我们的模板将它们显示出来。打开blog/views.py文件并输入：

先略过import那几行（它们载入了我们需要的函数和类），我们来逐行解释一下这个视图函数。

第5行：每个Django视图函数都将django.http.HttpRequest对象作为它的第一个参数。它还可以通过URLconf接受其他参数，你将来会大量用到这个特性。

第6行：当我们把BlogPost类作为django.db.model.Model的一个子类时，我们就获得了Django对象关系映射的全部力量。这一行只是使用ORM（对象关系映射，详见第3章和第4章）的一件简单例子，获取数据库里所有BlogPost对象。

第7行：这里我们只需告诉Django模板的名字就能创建模板对象t。因为我们把它保存在app下的templates目录里，Django无需更多指示就能找到它。

第8行：Django模板渲染的数据是由一个字典类的对象context提供的，这里的context c只有一对键和值。

第9行：每个Django视图函数都会返回一个django.http.HttpResponse对象。最简单的就是给其构造函数传递一个字符串。这里模板的render方法返回的正是一个字符串。

创建一个URL模式

我们的页面还差一步就可以工作了—和任何网页一样，它还需要一个URL。

当然我们可以直接在mysite/urls.py里创建所需的URL模式，但是那样做只会在项目和app之间制造混乱的耦合。Blog app还可以用在别的地方，所以最好是它能为自己的URL负责。这需要两个简单的步骤。

第一步和激活admin很相似。在mysite/urls.py里有一行被注释的示例几乎就是我们需要的代码。把它改成这样：

这会捕捉任何以blog/开始的请求，并把它们传递给一个你马上要新建的URLconf。

第二步是在blog应用程序包里定义URL。创建一个包含如下内容的新文件，mysite/blog/ urls.py：

它看起来和基本的URLconf很像。其中的关键是第5行，注意URL请求里和根URLconf匹配的blog/已经被去掉了—这样blog应用程序就变得可以重用了，它不用关心自己是被挂接到blog/下，或是news/下，还是what/i/had/for/lunch/下。第5行里的正则表达式可以匹配任何URL，比如/blog/。

视图函数archive是在模式元组第二部分里提供的。（注意我们传递的不是函数的名字，而是一个first-class的函数对象。当然用字符串也行，你在后面会看到。）

现在来看看效果吧！开发服务器还在运行中么？如果没有，执行manage.py runserver来启动它，然后在浏览器里输入http://127.0.0.1:8000/blog/。你可以看到一个简单朴素的页面，显示了所有你输入的blog帖子，有标题、发布时间和帖子本身。

2.9 最后的润色

你有好几种方式来继续改进这个基本的blog引擎。我们来讨论几个关键的概念，把这个项目弄得再漂亮一点。

模板的精确定位

毫不夸张地说，我们的模板实在是太平庸了。毕竟这是一本关于Web编程而不是Web设计的书，美术方面的东西你就自己处理吧，但是模板继承是模板系统里另一个能让你减少工作量的特性，特别是当你的页面风格快速成长的时候。

我们这个模板现在是自给自足的。但是如果我们的站点有一个blog、一个相册和一个链接页面，并且我们希望所有这些都能基于同一个基础风格的话该怎么办？经验告诉我们要是用复制粘贴的办法做出三个几乎完全一样的模板肯定是不行的。在Django里正确的做法是创建一个基础模板，然后在这之上扩展出其他特定模板来。在mysite/blog/templates目录里，创建一个叫做base.html的模板，其内容如下：

虽然不是完全符合XHTML Strict标准，不过差不多就行了。这里要注意的细节是{% block ... %}标签。它定义了一个子模板可以修改的命名块（named block）。修改archive.html模板，让它引用新的基础模板和它的“content”块，就能在blog app里使用它了。

这里的{% extends ... %}标签告诉Django去查找一个叫base.html的标签，并将这个模板里命名块的所有内容填入到那个模板里相应的块里去。现在你应该可以看到类似图2.10的页面了（当然了，你的blog内容比我这个应该更加精彩）。

图2.10 稍微带点风格的blog

按日期排序

你应该已经注意到blog的帖子不是按照传统的时间倒序排列的。告诉Django这么做非常简单。实际上，有好几种做法可供选择。我们可以在model里加入一个默认的顺序，或者在视图代码里的BlogPost.objects().all()上添加排序功能。在这里修改model会比较好，因为基本上帖子都是按时间倒序排列的。如果在model里设置我们想要的排序方式，Django里任何访问数据的部分都会采用这个排序结果。

设置model默认排序的方法是给它定一个Meta嵌套类，然后设置ordering属性。

现在看一下blog的首页（/blog/）。最新的帖子应该出现在页面最上方了。字符串“-timestamp”能简洁地通知Django，“对‘timestamp’变量按照降序排列”。（如果省略“-”的话则是按升序排列。）

注意

千万不要忘了小括号里结尾的那个逗号！它代表这是一个单元素的元组，而不是一个带小括号的字符串。Django在这里要的是一个元组，你可以排序任意数目的变量。如果你在逗号后面加上'title'，并且你有两个相同发布时间的帖子“A”和“B”的话，“A”就会出现在前面。

通过模板过滤器格式化时间戳

虽然时间戳很好用，但是它的ISO8601格式却有点怪异。我们现在用Django模板系统里另一个很酷的特性：过滤器（filter）来把它弄得人性化一点。

由于这是一个表示层的（presentation）细节而非数据结构或是商业逻辑的细节，最适合它的位置应该是模板。打开archive.html文件并修改“post.timestamp”一行。

只需像这样用一个竖杠，或“管道”符号接在变量名后面（大括号内部）就能把过滤器应用于变量之上了。刷新blog首页。现在你可以看到日期的显示更加友好了（“July 7”）。

如果date过滤器的默认风格你也不喜欢的话，你可以传递一个strftime风格的格式化串作为它的参数。不过这里它用的不是Python里time模块的转换代码，而是PHP的date函数的格式化说明。例如，如果你要显示星期几，但是不要显示年份的话，代码就变成下面这个样子了：

这个格式化字符串会返回“Friday，July 6th”风格的日期。注意这里不要在冒号两边留有空格—Django的模板引擎对空格敏感。

2.10 总结

我们可以给这个blog引擎不停地加入新特性（很多人就是这么干的！），但是作为体验Django能力的话，希望你已经看的差不多了。在构建这个基本的blog app过程中你已经看到了好几个Django优雅、简洁的特性：

?内置的Web服务器能让开发工作自给自足，同时它能在代码被修改时自动重新加载你的代码。

?数据模型的创建采用纯Python方式完成，你不用编写维护任何SQL代码或XML描述文件。

?自动化的admin应用程序，提供了完整的内容编辑特性，甚至非技术背景的用户也能使用。

?模板系统，可以用来生成HTML、CSS、JavaScript以及任何文本输出格式。

?模板过滤器，可以在不解除应用程序商业逻辑的前提下修改表示层的数据显示（比如日期）。

?URLconf系统，在给予你URL设计极大灵活性的同时还能将应用程序特定的URL部分保留在其所属的应用程序内部。

下面是一些可以通过Django内建的特性就能添加到blog上的功能，这能

让你有个基本的概念：

?发布关于最新帖子的Atom或RSS feed（参见第11章）。

?添加一个搜索功能，让用户能迅速定位包含特定词句的blog帖子（参见第8章里的CMS例子）。

?用Django的“通用视图”来避免在views.py里编写任何代码（参见第10章里的Pastebin示例）。

到此你已经完成了Django基础的旋风之旅。第3章会总览Django中的关键组件和它们背后的设计哲学，以及简要地复述一下Web开发原则，它们不仅是对Django自身，而且也是对书后几章的经验教训总结。第4章将带你进入框架的细节，你会找到很多之前例子中碰到的关于“怎么样，为什么和什么是等等？”问题的解答。第4章之后你就会对框架有足够的理解，可以继续构建示例应用了：一个内容管理系统（CMS）、一个Pastebin、一个相册和一个基于Ajax技术的“live blog”。