Django

来自tomtalk
跳转至： 导航、 搜索

快速入门例子

安装Django

http://jingyan.baidu.com/article/466506580e7d29f549e5f8b6.html 

pip install Django                  # 安装django
django-admin startproject mysite    # 生成项目
python manage.py runserver          # 运行项目
python manage.py startapp polls     # 生成运用

项目 VS 应用

项目和应用有啥区别？应用是一个专门做某件事的网络应用程序——比如博客系统，或者公共记录的数据库，或者简单的投票程序。项目则是一个网站使用的配置和应用的集合。项目可以包含很多个应用。应用可以被很多个项目使用。

urls.py

函数 path() 具有四个参数，两个必须参数：route 和 view，两个可选参数：kwargs 和 name。

解决python3下mysqldb不支持

MySQLdb 只适用于python2.x，发现pip装不上。它在py3的替代品是：import pymysql

注：windows下，django用不了。

windows安装mysqlclient

pip install wheel
pip install mysqlclient-1.4.2-cp36-cp36m-win_amd64.whl
python manage.py migrate   # 生成相应数据库表

pyhton中__pycache__文件夹的产生与作用

今天和一新来的同事沟通，说他用python编写了一个工程，但在第一次运行后，发现工程根目录下生成了一个__pycache__文件夹，里面是和py文件同名的各种以 .cpython-35.pyc 结尾的文件，问同事都不太清楚，所以便抽空整理了一下该知识点。先解释下cpython-35，cpython代表的是c语言实现的Python解释器，-35代表的是版本为3.5版。

models.py

迁移是非常强大的功能，它能让你在开发过程中持续的改变数据库结构而不需要重新删除和创建表 - 它专注于使数据库平滑升级而不会丢失数据。我们会在后面的教程中更加深入的学习这部分内容，现在，你只需要记住，改变模型需要这三步：

  1. 编辑 models.py 文件，改变模型。
  2. 运行 python manage.py makemigrations 为模型的改变生成迁移文件。
  3. 运行 python manage.py migrate 来应用数据库迁移。

创建一个管理员账号

$ python manage.py createsuperuser

一个快捷函数： render()

「载入模板，填充上下文，再返回由它生成的 HttpResponse 对象」是一个非常常用的操作流程。于是 Django 提供了一个快捷函数，我们用它来重写 index() 视图： 

#polls/views.py
 
from django.shortcuts import render
from .models import Question
 
 
def index(request):
    latest_question_list = Question.objects.order_by('-pub_date')[:5]
    context = {'latest_question_list': latest_question_list}
    return render(request, 'polls/index.html', context)

设计哲学

为什么我们使用辅助函数 get_object_or_404() 而不是自己捕获 ObjectDoesNotExist 异常呢？还有，为什么模型 API 不直接抛出 ObjectDoesNotExist 而是抛出 Http404 呢？

因为这样做会增加模型层和视图层的耦合性。指导 Django 设计的最重要的思想之一就是要保证松散耦合。一些受控的耦合将会被包含在 django.shortcuts 模块中。

也有 get_list_or_404() 函数，工作原理和 get_object_or_404() 一样。

为什么要重构代码？

一般来说，当编写一个 Django 应用时，你应该先评估一下通用视图是否可以解决你的问题，你应该在一开始使用它，而不是进行到一半时重构代码。本教程目前为止是有意将重点放在以“艰难的方式”编写视图，这是为将重点放在核心概念上。

就像在使用计算器之前你需要掌握基础数学一样。

使用通用视图：代码还是少点好

通用视图将常见的模式抽象化，可以使你在编写应用时甚至不需要编写Python代码。

我们在这里使用两个通用视图： ListView 和 DetailView 。

DetailView 期望从 URL 中捕获名为 "pk" 的主键值，所以我们为通用视图把 question_id 改成 pk 。

自动化测试

pytest

pytest will run all files of the form test_*.py or *_test.py in the current directory and its subdirectories.

当需要测试的时候，测试用例越多越好

貌似我们的测试多的快要失去控制了。按照这样发展下去，测试代码就要变得比应用的实际代码还要多了。而且测试代码大多都是重复且不优雅的，特别是在和业务代码比起来的时候，这种感觉更加明显。

但是这没关系！ 就让测试代码继续肆意增长吧。大部分情况下，你写完一个测试之后就可以忘掉它了。在你继续开发的过程中，它会一直默默无闻地为你做贡献的。

但有时测试也需要更新。想象一下如果我们修改了视图，只显示有选项的那些投票，那么只前写的很多测试就都会失败。但这也明确地告诉了我们哪些测试需要被更新，所以测试也会测试自己。

最坏的情况是，当你继续开发的时候，发现之前的一些测试现在看来是多余的。但是这也不是什么问题，多做些测试也 不错。

如果你对测试有个整体规划，那么它们就几乎不会变得混乱。下面有几条好的建议：

  1. 对于每个模型和视图都建立单独的 TestClass
  2. 每个测试方法只测试一个功能
  3. 给每个测试方法起个能描述其功能的名字

表单操作

字段数据

无论用表单提交了什么数据，一旦通过调用 is_valid() 验证成功（ is_valid() 返回 True ），已验证的表单数据将被放到 form.cleaned_data 字典中。这里的数据已经很好的为你转化为Python类型。

注解：此时您依然能够直接从 request.POST 中访问到未验证的数据，但最好还是使用经验证的数据。

如何将创建时间设置为“默认当前”并且可修改

那么问题来了。实际场景中，往往既希望在对象的创建时间默认被设置为当前值，又希望能在日后修改它。怎么实现这种需求呢？

django中所有的model字段都拥有一个default参数，用来给字段设置默认值。可以用default=timezone.now来替换auto_now=True或auto_now_add=True。timezone.now对应着django.utils.timezone.now()，因此需要写成类似下面的形式： 

from django.db import models
import django.utils.timezone as timezone
 
class Doc(models.Model):
    add_date = models.DateTimeField('保存日期',default = timezone.now)
    mod_date = models.DateTimeField('最后修改日期', auto_now = True)

html页面从数据库中读出DateTimeField字段时，显示的时间格式和数据库中存放的格式不一致，比如数据库字段内容为2016-06-03 13:00:00，但是页面显示的却是Apr. 03, 2016, 1 p.m.

为了页面和数据库中显示一致，需要在页面格式化时间，需要添加 

<td>{{ infor.updatetime|date:"Y-m-d H:i:s" }}</td>

类似的过滤器。刷新页面，即可正常显示。

取自“http://wiki.tomtalk.net/index.php?title=Django&oldid=5558”