django admin.py settings 操作
dango, 怎么说呢，什么东西都内置了，什么东西都是自己的东西。用过flask, cherrypy, web.py, pyramid 等等python 框架后，再选用dango 觉得，理念有很大的区别。藏着掖着的嫌疑比较大，高度封装，但是操作起来貌似省事情。时间久了会不会python的标准库不知道怎么用了，呵呵～
这里一些简单的资料也许挺有用的。http://django-chinese-docs.readthedocs.org/en/latest/intro/tutorial01.html
http://django-chinese-docs.readthedocs.org/en/latest/intro/tutorial02.html
无论是从后台管理，还是数据库模型结构上。django里面都是自带的东西，所以看起来会非常不一样。
好在django有一个自带的 python manage.py shell , 可以实时进入终端来操作产查看具体项目应用。
django的doc里面有这样详细地说明过project和app是不同的。每个project里面可以多很多app，而多个app可以被选择使用，或者选择不被使用。这是django的一个方面的东西。相对而言，flask就是app，一个project就是一个app，呵呵，不管怎么叫，想要实现什么功能都是可以的。
以前有用过SQLAlchemy, 觉得操作数据结构很不错，可是django自带了 "from django.db import models" 所有的新建对象都是
类似于这样的，
都是这样的东西。原理都是一样的。
有个比较好用的工具是python manage.py syncdb
这样就可以把app里面所有的数据表格，有创建的就重新创建一遍。如果已经创建了的话，并不会覆盖。在一定程度上，比较智能。
不过，最过瘾的一点是什么？
这个有管理后台UI，这个可以帮助程序员去分析去理解到底数据结构是什么样的。
当django 的服务跑起来的时候，我们不妨看一下localhost:8000/admin 里面是什么样的。
django 是这样自动生成项目的
第一步
python manage.py startproject mysite
cd mysite
每当我们新建一个app的时候，
python manage.py startapp poll
现在我们来看看目录结构
mysite/ |-- db.sqlite3 |-- manage.py |-- mysite | |-- __init__.py | |-- __init__.pyc | |-- settings.py | |-- settings.pyc | |-- urls.py | |-- urls.pyc | |-- wsgi.py | `-- wsgi.pyc `-- polls |-- admin.py |-- admin.pyc |-- __init__.py |-- __init__.pyc |-- models.py |-- models.pyc |-- tests.py `-- views.py 2 directories, 18 files
因为应用poll 是我们要加入的project里面的，所以我们需要修改
mysite/mysite/settings.py
加上一行这样的东西，
然后，
mysite/polls/models.py
import datetime from django.db import models from django.utils import timezone # Create your models here. class Poll(models.Model): question = models.CharField(max_length=200) pub_date = models.DateTimeField('data published') def was_published_recently(self): # less than 1 days new, then True return self.pub_date >= timezone.now() - datetime.timedelta(days=1) # ... def __unicode__(self): return self.question class Choice(models.Model): poll = models.ForeignKey(Poll) choice_text = models.CharField(max_length=200) votes = models.IntegerField(default=0) # ... def __unicode__(self): return self.choice_text
django 是这样操作数据库的
然后要创建数据库，数据表，比如我们的app里面包含的那些。这里我们让django自动执行
python manage.py syncdb
数据库是选用sqlite的，所以文档目录下会生成一个db.sqlite3 的文件，这个文件可以使用sqlite3 打开。
里面会创建几个已经建立好的数据表。
我们看一下：
django 就是这样自动生成的，不要问为什么了。当然可以自己修改。这是由于django的db model的原因
polls_choice (polls 是app名称， choice 是里面的新建的表名，表名就是一个类名，我们可以看到。结合曾经的SQLAlchemy 应该比较好理解）
好了，现在我们到polls_poll 表里面看看。
为什么出现这些东西呢？
是因为我们可以对数据库API 直接进shell 操作。好在django 有这样一个工具
python manange.py shell
（上面的截屏是由于我已经做了一些关于数据库方面的操作了，在python shell 的django API里面，下面的截屏是在什么数据操作都没有执行的情况下的）
进入后，
我们就做
（参考地址http://django-chinese-docs.readthedocs.org/en/latest/intro/tutorial01.html）
上面的操作很酷，也很简单，简单到完全没有感受到SQL语言的痛苦，哈哈，这也是未来noSQL的发展趋势之一！
基本上知道数据能做什么就可以了，别的不用太担心。
这个可以参考教程：http://django-chinese-docs.readthedocs.org/en/latest/intro/tutorial02.html
django是用来看和点击鼠标的
你会发现，很多有意思的东西，比如说操作mysite/poll/admin.py 文档，
可以控制app poll 的各种数据表model.py 里的类，在django admin里面显示的样式。
方法有如下的内容：
mysite/polls/admin.py
已经被我改成这样了：
#-*- coding: utf-8 -*- from django.contrib import admin from polls.models import Poll from polls.models import Choice class ChoiceInline(admin.TabularInline): """ 还有个小问题。为了显示所有关联 Choice 对象的字段需要占用大量的 屏幕空间。为此，Django 提供了一个以表格方式显示内嵌有关联对象的方式； 你只需要将 ChoiceInline 声明改为(admin.TabularInline)： """ #class ChoiceInline(admin.StackedInline): """ 根据字面意思，也能理解，这个是为了给把(已经有foreign key指向到class Poll 的) class Choice ，把它堆叠在django admin 的Poll对象显示界面里面。看Poll的时候，就也能看到是谁的foreign key指向到了Poll了。 这让让进入后台管理看起来，多了三个为关联Choices提供的输入插槽 - 由extra指定，并且每次你在"Change"页修改已经创建的对象时，都会另外获得三个额外插槽 """ model = Choice extra = 3 # In this way to enable its app's admin function #class PollAdmin(admin.ModelAdmin): # fields = ['pub_date', 'question'] class PollAdmin(admin.ModelAdmin): ''' 字面意思就是给管理界面设置规则 这样做纯粹是为了在后台方便看 django 让人变懒了，但是这样更有助于编程。 通过这种方式，可以在admin后台里更清晰地看数据结构 ''' fieldsets = [ (None, {'fields':['question']}), ('Date information', {'fields':['pub_date']}), ] inlines = [ChoiceInline] # Register your models here. admin.site.register(Poll, PollAdmin) #admin.site.register(Poll) admin.site.register(Choice)
所以我看到的展示页面是这样的：
这里，django让你可以自定义管理界面 http://django-chinese-docs.readthedocs.org/en/latest/intro/tutorial02.html#id7
What a CMS!
纠结到底是纯粹写代码，还是纯粹看UI点鼠标。可能会陷入两者之间。如果你是tmux用户，你会怎么想？ :$
我们先来看看原本的
django是这样用来玩web admin CMS的
看起来有些单调，有很多关于这个数据表poll的行（这里两条数据）都没有明确的显示出来
现在我们看一下这里的好东西
现在我们在mysite/polls/admin.py这加上这一行之后
看看
再来看看
看到多了数据Question , Data published, Was published recently (每个词开头竟然大写，跟数据库里面的表很不一样呀，不标准！！！）
这里用sqlitebrowser 看db.sqlite3 数据库文件里的polls_poll 表，
比较一下创建数据库的时候的models.py 关于polls_poll 表的是怎么定义的
上面三个被红色标注出来的是模块在django admin界面里面我们能看到的。现在我们知道django 看来不是对任何数据库操作变量一视同仁了
数据库里面就是只有单一的id, question, pud_date 栏目 （这里的id都是django自己生成的）
逆向工程思维，django web admin 和 models.py 在沟通的过程中，是按照上面的不公平起名字方法进行talk的。
————To Be Continued————
_____Back !______
22:25 2013 Dec 13th
通过上面我们总结一下django的web admin界面里面，对数据库模型model的展示方式是这样的：
对字符串/数字类型 采用属性名称，
对日期类型的，采用pub_date = models.DateTimeField('date published') 里的date published
对布尔类型的，采用def 后的函数名称，
在admin.py ,
加上这行很不错的样子。
list_display('question', 'pub_date', 'was_published_recently')
效果如上面的图所示。
现在我们要在数据库表格里面添加别的东西，用来以另外的方式显示数据库表单内容
如下图所示：
图显示的很明白了，添加了三行（视图规则，django CMS特有的）在mysite/poll/models.py 里面，
添加了一行（显示规则）在mysite/poll/admin.py里面
就产生了如上效果，可以结合和以前的比较一下，还是有一些不同的。
请注意，这里所指的所有的关于搜索的内容的依据，例如 search_fields = ['question'] 都是models.py 里面的属性的名称，而非实际数据库里面的表名。django这么做，完全是相当于自己内置了一套数据库系统，不用数据库语言，便可查看操作数据库。想想当年用phpmyadmin的时候，为什么没有PHP CMS里面内置一套这样的不用借助SQL语言就能各种过滤调用数据库数据呢？！这才是大势所趋嘛，NoSQL！
我们再来添加一点瓦
可以达到这个效果！
效果还不错。以后都不用用SQL啦。让SQL见鬼去了。
