zoukankan      html  css  js  c++  java
  • 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见鬼去了。

  • 相关阅读:
    [c++ 11x rvalue reference]
    Exception Cost
    How to set NoStepInto for VS debugging
    STL算法find_if和find
    [转载]The Biggest Changes in C++11 (and Why You Should Care)
    QT信号和槽
    读《构建之法》前三章有感
    复利计算器(3)——数据库
    《构建之法》——第四章
    操作系统命令行解释
  • 原文地址:https://www.cnblogs.com/spaceship9/p/3473666.html
Copyright © 2011-2022 走看看