Django

1) mysite/wsgi.py：用于你的项目的与WSGI兼容的Web服务器入口。
2) migrate查看INSTALLED_APPS设置并根据mysite/settings.py文件中的数据库设置创建任何必要的数据库表，数据库的迁移还会跟踪应用的变化。你会看到对每次迁移有一条信息。如果你有兴趣，可以运行你的数据库的命令行客户端并输入dt (PostgreSQL), SHOW TABLES; (MySQL)或.schema (SQLite)来显示Django创建的表。
3) 应用是一个Web应用程序，它完成具体的事项 —— 比如一个博客系统、一个存储公共档案的数据库或者一个简单的投票应用。 项目是一个特定网站中相关配置和应用的集合。一个项目可以包含多个应用。一个应用可以运用到多个项目中。
4) 当编写一个数据库驱动的Web应用时，第一步就是定义该应用的模型 —— 本质上，就是定义该模型所对应的数据库设计及其附带的元数据。
迁移完全依照于你的模型文件且本质上只是一个历史记录，Django通过这个历史记录更新你的数据库模式使它与你现在的模型文件保持一致。
python manage.py migrate

python manage.py makemigrations polls(通过运行makemigrations告诉Django，已经对模型做了一些更改（在这个例子中，你创建了一个新的模型）并且会将这些更改存储为迁移文件。)
Django使用迁移文件来保存对模型的更改（即数据库模式的更改）—— 所谓迁移文件其实就是磁盘上的普通文件。
python manage.py sqlmigrate polls 0001(sqlmigrate命令接收迁移文件的名字并返回它们的SQL语句)
python manage.py check；会检查你的项目中的模型是否存在问题，而不用执行迁移或者接触数据库。
python manage.py migrate(migrate命令会找出所有还没有被应用的迁移文件（Django使用数据库中一个叫做django_migrations的特殊表来追踪哪些迁移文件已经被应用过），并且在你的数据库上运行它们 —— 本质上来讲，就是使你的数据库模式和你改动后的模型进行同步。)

实现模型变更的三个步骤：修改你的模型（在models.py文件中）。

运行python manage.py makemigrations ，为这些修改创建迁移文件

运行python manage.py migrate ，将这些改变更新到数据库中。

python manage.py shell

export DJANGO_SETTINGS_MODULE="mysite.settings"
python >> import django >> django.setup()
5) python manage.py createsuperuser

admin.site.register(Question)

class QuestionAdmin(admin.ModelAdmin):

fields = ['pub_date', 'question_text']

admin.site.register(Question, QuestionAdmin)
当你需要为一个对象修改管理选项的话，就按照这样的步骤来做：创建一个模型管理对象，然后把该对象作为第二个参数传入admin.site.register()。

#class ChoiceInline(admin.StackedInline):

class ChoiceInline(admin.TabularInline):
model = Choice
extra = 3

class QuestionAdmin(admin.ModelAdmin):
fieldsets = [
(None, {'fields': ['question_text']}),
('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}),
]

inlines = [ChoiceInline]
list_display = ('question_text', 'pub_date', 'was_published_recently')
list_filter = ['pub_date']
search_fields = ['question_text']
Django不支持按照随便一个方法的输出进行排序。

模板可以放在你的文件系统中Django所能访问到的任何地方。 （运行Web服务器的用户即是运行Django的用户）。然而，把模板放在项目目录下会是一个值得提倡的、应该遵循的约定。
DIRS 是加载Django模板时检查的一个文件系统目录列表；它是一个搜索路径。
Django源文件在系统上的位置: python -c "import django; print(django.__path__)"
由于APP_DIRS设置为True，Django会自动地在每个应用包下面查找一个templates/子目录，留作备用。

视图
Django使用叫做‘URLconfs’的配置来为URL匹配视图。 一个URLconf负责将URL模式匹配（使用正则表达式）到视图。
url()参数: regex 正则表达式不会检索URL中GET和POST的参数以及域名。性能方面的一个注意点：这些正则表达式会在URLconf模块第一次载入的时候被编译。
当Django找到一个匹配的正则表达式时，它就会调用view参数指定的视图函数，并将HttpRequest对象作为第一个参数，从正则表达式中“捕获”的其他值作为其他参数，传入到该视图函数中。如果正则表达式使用简单的捕获方式，值将作为位置参数传递； 如果使用命名的捕获方式，值将作为关键字参数传递。
url()参数: name
命名你的URL。 这样就可以在Django的其它地方尤其是模板中，通过名称来明确地引用这个URL。 这个强大的特性可以使你仅仅修改一个文件就可以改变全局的URL模式。当有人请求你的网站的一个页面时，Django将加载mysite.urls Python 模块，因为ROOT_URLCONF设置指定了它。模板命名空间现在，我们可以直接将我们的模板放在polls/templates中（而不用创建另外一个polls子目录），但实际上这是个坏主意。Django将选择它找到的名字匹配的第一个模板文件，如果你在不同 的应用有相同名字的模板文件，Django将不能区分它们。我们需要将Django指向正确的模板，最简单的方式是使用命名空间。具体实现方式是，将这些模板文件放在以应用的名字来命名的另一个目录下。Context是一个字典，将模板变量的名字映射到Python 对象。
常见的习惯是载入一个模板、填充一个context 然后返回一个含有模板渲染结果的HttpResponse对象。
forloop.counter指示for标签已经循环多少次。

所有针对内部URL的POST表单都应该使用{% csrf_token %}模板标签。

你应该在成功处理POST数据后总是返回一个HttpResponseRedirect。 这不是Django的特定技巧；这是那些优秀网站

python manage.py test polls查找polls 应用下的测试用例
它找到 django.test.TestCase 类的一个子类
它为测试创建了一个特定的数据库
它查找用于测试的方法 —— 名字以test开始
它运行test_was_published_recently_with_future_question创建一个pub_date为未来30天的 Question实例
... 然后利用assertEqual()方法，它发现was_published_recently() 返回True，尽管我们希望它返回False

每个模型或视图具有一个单独的TestClass
为你想测试的每一种情况建立一个单独的测试方法
测试方法的名字可以描述它们的功能

{% load staticfiles %} 从staticfiles模板库加载{% static %} 模板标签。{% static %}模板标签会生成静态文件的绝对URL。

模型中的每个字段都是 Field 子类的某个实例。Django 根据字段类的类型确定以下信息：
数据库当中的列类型 (比如: INTEGER, VARCHAR)。
渲染表单时使用的默认HTML 部件（例如，<input type="text">, <select>）。
最低限度的验证需求，它被用在 Django 管理站点和自动生成的表单中。

主键字段是只读的。如果你在一个已存在的对象上面更改主键的值并且保存，一个新的对象将会在原有对象之外创建出来。