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 里面是什么样的。
第一步
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
然后要创建数据库,数据表,比如我们的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
你会发现,很多有意思的东西,比如说操作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用户,你会怎么想? :$
我们先来看看原本的
看起来有些单调,有很多关于这个数据表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见鬼去了。