标签归档:django

SAE部署Django1.3应用问题总汇

花了些工夫将碎片网部署到了SAE,中途遇到各类问题。感觉SAE看上去很美,实际上却并不是太成熟(至少python版如此)。
下面记录下我遇到的一些主要问题以及解决方法。

django版本问题

Django1.4都即将发布了,SAE平台自带的SAE版本依旧为1.2x。为使用django1.3版本,你需上传自己的django。具体做法可参考SAE手册中的runtime.html#virtualenv

日志模块出错

最先遇到的是日至模块的问题。错误显示AdminEmailHandler中构造某个类时带了is_mail这个参数,但目标类的构造函数根本就不支持。好在日至模块不是必须。将日至处理模块换成django.utils.log.NullHandler解决问题。

'null’: { 'level’:'DEBUG’, 'class’:'django.utils.log.NullHandler’, },

local_thread问题

在index.wsgi中加入

import threading
from django.utils import _threading_local
threading.local = _threading_local.local

settings文件

SAE默认安装了不少python包,其中包括django-userena。糟糕的是SAE将django-userena的demo项目也加到了python路径,而且加载的优先级比项目代码还高。直接导致os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘settings’找到的是userena的settings文件。最终将settings文件改名为qnotes_settings.py解决该问题。

其他问题

  • 昨天部署上线后经常出现数据库错误,错误提示为Caught OperationalError while rendering: (1045, ‘access deny’)  。SAE数据库不支持长连接,30s后主动超时。但django本就会在每次请求后自动关闭数据库连接,理论上不应当出现类似问题。该问题今天莫名其妙的自己好了。
  • 服务器非常不稳定,经常长时间的无法访问,不定期的可以正常访问。
  • SAE可能hack了python的包加载机制的原因,SAE的python包的加载行为有些奇怪。本应当最先加载当前目录下的包,实际上却不一定。

timeline项目开发日志–登陆、注册模块

利用twitter/bootstrap,项目的基础模板算是顺利搞定。接下来开始处理用户中心。
用户中心主要包括用户登陆、注册以及头像等个人信息维护。此前,用户的注册管理我一直使用django-registration。只是这个APP有些不思进取,09年发布了0.8alpha版后就一直没什么动静。这次决定尝试另外一个用户模块组件django-userena
相比django-registration,django-userena的功能要完善的多。除基础的登陆注册模块外django-userena甚至还带了站内消息功能。django-userena的易用性方面也做的非常的不错。django-userena自带了默认模板,并有提供一个完整的演示项目,让你可以轻松上手。这里有个官方的在线demo,感兴趣可以去看看

django-userena同twitter/bootstrap的整合

我们自然是希望所有的APP不用做任何修改,拿来就能用了。不过事与愿违,在整合的过程中多多少少都会遇到一些问题。django-userena默认的模板在项目中显示的非常难看。我们需要重写django-userena的默认模板,并且用django-bootstrap来生成form。
forms.py

#为原始form添加BootstrapMixin
from bootstrap.forms import BootstrapMixin
class BsAuthenticationForm(AuthenticationForm, BootstrapMixin):
    def __init__(self, *args, **kw):
        super(BsAuthenticationForm, self).__init__(*args, **kw)
        self.__bootstrap__()

urls.py

#重写urls,指定使用的form
from django.conf.urls.defaults import *
from userena import views as userena_views
from profiles.forms import BsSignupForm, BsAuthenticationForm
urlpatterns = patterns('',
    url(r'^signup/

中文用户名问题

同django-admin一样,django-userena也无法使用中文进行注册。对于一个中文网站而言,不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验,重写注册form修改认证规则即可取消该限制。

USERNAME_RE = r'^\S+
, userena_views.signup,
        {'signup_form': BsSignupForm}, name='userena_signup'),
    url(r'^signin/

中文用户名问题

同django-admin一样,django-userena也无法使用中文进行注册。对于一个中文网站而言,不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验,重写注册form修改认证规则即可取消该限制。

USERNAME_RE = r'^\S+$'
attrs_dict = {'class': 'required'}
class BsSignupForm(SignupForm, BootstrapMixin):
    username = forms.RegexField(regex=USERNAME_RE,
                                max_length=30,
                                widget=forms.TextInput(attrs=attrs_dict),
                                label=_("Username"),
                                error_messages={'invalid': _('Username must contain only letters, numbers, dots and underscores.')})
    def __init__(self, *args, **kw):
        super(BsSignupForm, self).__init__(*args, **kw)
        self.__bootstrap__()

Django数据库迁移组件(South)

django提供syncdb命令,用于从models自动生成数据库。但在models结构变化后,syncdb并无法自动实现数据库的更新。South组件即是为了解决该问题而出现的。
下面简单介绍一下South的一些最常见用法,更详细的使用方法见South的官方手册。

假设我们创建了一个名叫southtut的app

  1. 生成初始化数据库的south脚本。允许上述命令后将在对于的app目录下生成 migrations目录,south的数据库迁移脚本即保存在该目录。
    ./manage.py schemamigration southtut --initial
  2. 在所用south后,syncdb命令不会为使用south托管的app生成数据库。migrate命令用于执行south的数据库迁移脚本, 实现数据库更改。在这里执行的操作是为southtut创建相关的数据库表。不带app名字时,将对project中的所有app进行migrate操 作。
    ./manage.py migrate southtut
  3. 在很多应用场景中,我们已经用syncdb将数据库给创建好了。这时候运行上面的migrate命令将会提示相关表已经存在,命令执行失败。这 时候我们需要告诉south需要跳过某些migrate操作。上面的命令将告诉south,系统已经执行过了0001号数据库迁移脚本。
    ./manage.py migrate southtut 0001 --fake
  4. 接下来我们对models进行了某些改动,修改后增减了某些字段。
  5. 该命令将自动生成数据库的迁移脚本。在migrations目录下可以看到新增加了文件0002_xxx.py,该文件即是此次models改 动的数据库升级脚本。打开文件后可看到其中有一个类Migration,类中有两个方法forwards和backwards。这两个方法分别实现数据库 升级和会滚时对数据库的操作,具体指令的含义参考south的数据库API
    ./manage.py schemamigration southtut --auto
  6. 应用models的改动到数据库
    ./manage.py migrate southtut

合理的组织django的settings文件

django在一个项目的目录结构划分方面缺乏必要的规范,因此不同人的项目组织形式也千奇百怪,而且也很难说谁的做法就比较好。我根据自己的项目组织习惯,发布了一个项目dj-scaffold
前些天在reddit上为我的项目dj-scaffold打了个“广告”(见:http://redd.it/kw5d4)。不想评价甚糟,甚至差点被打成负分。其中更也人将这个项目说的一文不值。面对负面声音虽然会有些不爽,但其中的建设性意见还是需要听取的,至于那些纯属个人偏好部分就自动过滤了。
在谈及settings文件如何组织时,coderanger建议参考The Best (and Worst) of Django中的做法。文中的主要观点是开发环境和生产环境的配置都需要放到VCS中进行版本控制。参考文中的做法,我对settings模块做了部分调整。注:代码 https://github.com/vicalloy/dj-scaffold/tree/master/dj_scaffold/conf/prj/sites/settings

local_settings的弊病

为将项目的默认配置和本地配置区分开,最常用的做法是增加一个local_settings.py文件,并在settings文件的最后对该文件进行import。

try:
    from local_settings import *
except:
    pass

由此引发的问题是你不能对local_settings.py进行版本控制,部署环境的配置万一丢失将难以找回。

解决方案

针对该问题,建议的解决方案如下

合理的配置文件组织方式

|~settings/
| |-__init__.py
| |-base.py   #默认配置信息
| |-dev.py    #开发环境的配置
| |-local.sample    #本地的扩展配置在dev和production的最后进行import
| |-pre.sample    #设置当前使用的配置为生产环境还是开发环境
| `-production.py    #生产环境的配置

使用方式

DJANGO_SETTINGS_MODULE

django的admin脚本提供了settings参数用于指定当前使用的配置文件

django-admin.py shell --settings=settings.dev

在wsgi脚本中则可直接设置需要使用的settings

deploy.wsgi
os.environ['DJANGO_SETTINGS_MODULE'] = settings.production

简化参数
当然,如果每次使用django-admin.py的时候都要带上settings参数还是非常恼人,所以推荐的做法是在pre.py中配置自己所需要使用的配置文件。

SETTINGS = 'production' #dev

Django标准化项目dj-scaffold

由于Django没有象rails一样指定项目的目录结构规范,很多人都对django项目的目录结构要如何组织而感到困惑。为此我又新创建了一个开源项目dj-scaffold(django的脚手架)。这个项目用于自动生成一个标注化的django项目和app。

项目地址:https://github.com/vicalloy/dj-scaffold

安装

已经发布到了pypi,所以你可以用pip或easy_install 来进行安装。

pip install dj-scaffold
easy_install dj-scaffold

使用

dj-scaffold主要提供了两个命令,dj-scaffold.pylbstartapp

dj-scaffold.py

该脚本用于取代django的startproject命令。使用方式如下:

dj-scaffold.py projectname 

在该命令执行后,将创建项目projectname。在项目的scripts目录中提供了脚本create_env.pyenv.rc

  • create_env.py 执行该脚本将自动初始化python虚拟环境。新生成的python虚拟环境在env目录。
  • env.rc 该脚本用户启动python虚拟环境(source env.rc)。该脚本同时为python manage.py设置了快捷方式$mg。你可以在任何目录调用$mg来执行django命令。比如你用$mg runserver来启动测试服务器。

项目对应的目录结构如下:

注:文件太多,去掉了部分不重要的文件
dj-scaffold.py projectname 
|+docs/    #用于存放项目的相关文档
|+env/     #python虚拟环境,由脚本自动生成
|~requirements/     #第三方依赖包的存放位置
| `-requirements.pip    #pip的依赖说明文件
|~scripts/    #系统相关的脚本
| |-create_env.py    #创建python虚拟环境(env目录)
| `-env.rc    #进入python虚拟环境。同时提供python manger.py的快捷方式$mg。可在任意目录使用$mg。
|~sites/    #Django的项目文件。在settings文件中增加了部分默认配置。如数据库默认使用sqlite,设置项目的模板以及静态文件目录。
| |+media/    #项目静态文件(用户上传)
| |+static/    #项目静态文件(css、js等)
| `+templates/    #项目模板
|+tools/    #一些项目依赖的第三方工具包。如python虚拟环境初始化脚本等。
`~wsgi/    #项目部署用的wsgi文件
  `-dj_scaffold.wsgi

lbstartapp

lbstartapp作为django的扩展命令提供。将dj_scaffold加到INSTALLED_APPS后即可使用该命令。该命令将生成一个标准的app,相比django自带的startapp,lbstartapp将那些不太常用的app默认目录也都给生成了出来。对应目录结构如下:

|+management/    #命令目录
|+static/    #静态文件目录
|+templates/    #模板目录
|+templatetags/    #tag目录
|-__init__.py
|-admin.py    #admin管理后台的models配置文件
|-forms.py
|-models.py
|-settings.py    #app自己的settings文件
|-tests.py
|-urls.py    #urls配置文件
`-views.py

NOTE

  • 项目的大多代码来自:https://github.com/lincolnloop/django-startproject
  • 类似项目:https://github.com/mozilla/playdoh 个人觉得这个项目还可以。不过我个人觉得自己写的更符合自己的习惯。
  • “摒弃魔法”是Django的哲学之一。为此Django没有为用户提供太多的默认操作,它希望一切对用户都是显示可见的。这本没太大的问题,但在我看来“no magic”并不代表连规范都不要。Django实在是太缺乏一些必要的规范。

django1.3的staticfiles

django1.3新加入了一个静态资源管理的app,django.contrib.staticfiles。在以往的django版本中,静态资源的管理一向都是个问题。部分app发布的时候会带上静态资源文件,在部署的时候你必须手动从各个app中将这些静态资源文件复制到同一个static目录。在引入staticfiles后,你只需要执行./manage.py collectstatic就可以很方便的将所用到app中的静态资源复制到同一目录。

staticfiles的引入,方便了django静态文件的管理,不过感觉staticfiles的文档写的并不是太清楚,初次使用的时候还是让我有些困惑。

下面简单的介绍一下staticfiles的主要配置:

  • STATIC_ROOT:运行manage.py collectstatic后静态文件将复制到的目录。注意:不要把你项目的静态文件放到这个目录。这个目录只有在运行collectstatic时才会用到。我最开始想当然的以为这个目录和MEDIA_ROOT的作用是相同的,致使在开发环境下一直无法找到静态文件。
  • STATIC_URL:设置的static file的起始url,这个只可以在template里面引用到。这个参数和MEDIA_URL的含义差不多。
  • STATICFILES_DIRS:除了各个app的static目录以外还需要管理的静态文件位置,比如项目公共的静态文件差不多。和TEMPLATE_DIRS的含义差不多。
  • 各个APP下static/目录下的静态文件django的开发服务器会自动找到,这点和以前APP下的templates目录差不多。
  • urls.py中加入静态文件处理的代码
    from django.contrib.staticfiles.urls import staticfiles_urlpatterns
    # ... the rest of your URLconf goes here ...
    urlpatterns += staticfiles_urlpatterns()

simple-todo (Django 版)

项目地址:https://github.com/vicalloy/django-simple-todo

缘起

simple-todo最早是web.py一个中文教程的例子。后来Uliweb的作者limodou 认为这个教程很不错,于是有了Uliweb版的simple-todo。接着又有了Bottle版和Flask版。这俨然成了一个FrameworksShow项目。既然是FrameworksShow, 那Django的总不应当缺了吧。
simple-todo: 一个简易的 todo 程序
http://simple-is-better.com/news/309
Simple Todo (Uliweb 版本) 教程 by @limodou
http://simple-is-better.com/news/312
Simple-TODO Bottle 实现版 by @zoomquiet
http://simple-is-better.com/news/509
Simple-TODO Flask实现版 by @wyattwang
http://simple-is-better.com/news/524

运行需求

Django>=1.3

安装及运行

初始化数据库: python manage.py syncdb
启动: python manage.py runserver
使用: 在浏览器中打开 http://127.0.0.1:8000/
Django Admin: 在浏览器中打开 http://127.0.0.1:8000/admin/

项目开发记录

  1. 创建django project和app:
    django-admin.py startproject simple_todo_site
    cd simple_todo_site/
    python manage.py startapp simpletodo
  2. 编辑settings.py完成数据库、模板、静态文件等配置,主要配置条目:
    #注:我认为django应当加更多的默认设置,这些配置改的挺烦
    DATABASES
    INSTALLED_APPS
    STATIC_ROOT
    STATICFILES_DIRS
    TEMPLATE_DIRS
  3. 编辑urls.py把django admin和static文件url配置加上。
  4. 编辑simpletodo/models.py,完成数据模型:
    from django.db import models
    from django.contrib import admin
    class Todo(models.Model):
        title = models.CharField( max_length=255)
        finished = models.IntegerField(default=0)
        def __unicode__(self):
            return self.title
  5. 创建数据库:
    python manage.py syncdb
  6. 跑起来,进django admin看看先:
    python manage.py runserver
    #http://127.0.0.1:8000/admin/
  7. 接下来,略…

发布一个Django的论坛系统LBForum(开源、带演示)

简介

LBForum 用django开发的论坛系统,演示地址为:http://vik.haoluobo.com/lbforum/
项目的地址为:http://github.com/vicalloy/LBForum
界面部分抄的 FluxBB(一个开源的PHP论坛 http://fluxbb.org/ )。
虽然Django写的论坛也不少,不过还真没什么好用的。
大多Django论坛都是独立的app,而且不少还缺模板,想我这样有经验的Django用户要跑起来都觉得麻烦,其他普通用户就更别说了。
LBForum主要注重部署的方便性和易用性,功能方面目前还比较简单。
LBForum一开始就是以整站的形式提供,所以以LBForum做为基础项目进行二次开发是很容易的。
同时LBForum的开发尽量遵照Django可复用app原则,因此即使需要将LBForum做为独立的app集成到其他项目也并不会太难。

主要功能

目前功能还比较简单,而且还有些小问题有待修正。

  1. 论坛分类,分版块
  2. 发帖,回帖
  3. BBCode支持
  4. 置顶贴
  5. 使用django admin提供论坛管理功能

用开发服务器把LBForum跑起来

  1. 先把代码down下来。LBForum托管在github上,http://github.com/vicalloy/LBForum 。如果你没有安装git,你可以直接用界面右上方的download
    source功能下载代码。
  2. 运行\scripts\create_lbforum_env.py初始化lbforum的python虚拟环境。该脚本会自动创建一个python的虚拟环境并使用easy_install安装对应的依赖包,同时将一些依赖包解压到对应的目录中。
    注:django使用的是svn版本,所以机器上必须要安装有SVN,不然脚本会运行失败。如果因为由于svn的问题导致脚本运行失败,可以运行lbforum_env.bat进入lbforum环境,手动安装django的svn版本。
  3. 环境初始化好后,运行lbforum_env.bat进入lbforum环境
  4. 运行%mg% syncdb初始化数据库
  5. 运行%mg% runserver启动django开发服务器
  6. 进入admin,创建论坛分类和版块
  7. 进入版块发帖

LBForum的目录结构说明

|+lbforum_env/#lbforum运行的python虚拟环境,运行create_lbforum_env.py后自动创建
|+requirements/#lbforum用的第三方库和app,运行的时候会将该目录加到python路径
|~scripts/#工程相关脚本
| |-create_lbforum_env.py#初始化python虚拟环境,并自动安装easy_install/django依赖库
| |-helper.py#提供其他脚本所需的辅助函数
| `-lbforum_env.bat*#启动lbforum运行的虚拟环境及,并为lbforum的manage.py提供快捷方式%mg%,比如初始化数据库%mg%
syncdb
|~sites/#站点配置/模板/静态文件
| `~default/#默认站点
|   |+static/#静态资源文件,如css等
|   |+templates/#Django模板目录
|   |+templates_plus/#Django模板目录,用户将自己重写过的目标放到该目录
|   `-……
|~src/#django的app目录
| |+account/#account相关app。具体站点通常会对用户中心进行定制,所以该app在实际应用中很可能需要针对实际情况进行修改。
| |+djangohelper/#一些django的辅助函数等,
| |+lbforum/#lbforum的主app,论坛功能都在改app中
| |+lbregistration/#registration app的lbforum扩展,主要去掉邮件地址认证功能
| |+onlineuser/#显示在线用户的app(可复用的django app,可脱离lbforum单独使用)
| `+simpleavatar/#头像功能的app(可复用的django app,可脱离lbforum单独使用,依赖djangohelper)
|+tools/#工程用到的辅助工具,目前只有一个virtualenv的脚本

注:

  1. 由于计划在以后做i18n,所以目前只提供英文界面
  2. django的错误提示是显示在字段后面,fluxbb的错误全部都显示在表单前面。由于模板没有调好,所以目前按照fluxbb的方式显示错误,所以错误显示有些不太正常。
  3. bbcode的输入框本想做成自适应大小的,不过也调得有些问题,所以现在输入框的大小固定。
  4. 文档… ,感觉好难写-_-,目前文档不全(项目中没有带任何的文档),日后补上。
  5. 应用程序的目录结构主要查看pinax
  6. simpleavatar模块部分代码来自django-avatar
  7. 依赖包除用easy_install在线安装的外,尽量使用zip包的方式附带在项目中,减少安装依赖包的困难。
  8. 远程部署脚本计划使用fabric,但fabric本身安装比较麻烦,所暂未处理。
  9. 项目最早放在googlecode,不过感觉github的功能更强些,所以移了过去。

django的论坛app

在django的资源页面里有个第三方论坛app的比较页面Django Forum Apps Comparison。一眼望过去,可用的app还不真不少,数下了有15个之多。但真正看下来,似乎很难找到一个让人满意的。
我对论坛app的要求是:

  1. 得要自带一个还比较漂亮的界面模板。
    模板的开发工作在django应用的开发中占了很大的比重,甚至可能比写python代码花的时间还多。可惜的是很多的app应用甚至连个最基础的demo模板都没带。
  2. 最好支持Richeditor和BBCode。
    支持BBCode的app还是有几个的。Richeditor的支持基本上属于模板的范畴,参考条目1,似乎还没看到支持Richeditor的论坛(注:我没每个app都看,不能确定,pybb默认模板带了个Markup的编辑器)。
  3. 支持附件。
    国内的论坛应用大多偏娱乐,用户喜欢在自己的帖子里插入图片等东西。虽然可以再单独提供一个上传附件的组件,让用户上传后再在论坛里引用,但用户体验就要差不少了。

既然找不到满意的app,那就只能自己动手做了。目前计划在pybb(注:pybb的许可协议没看太懂,似乎是类似BSD的)的基础上进行开发。目前的开发计划如下:

  1. 先给项目换个新名字LBForum
  2. 换个漂亮些的模板(同时增加richeditor)
    考虑过不少模板。

    • phpbb3 目前最流行的开源论坛程序,css和html写得很不错。但似乎有些复杂了,套用起来有些麻烦。
    • phpbb2/javaeye/jforum 这几论坛程序都长得差不多,UI应当都是参照phpbb2(javaeye的老大自己说了javaeye的界面就是仿phpbb3)来做的。其实也不能说这几个论坛的模板有什么不好。更多的是不喜欢里面过多的table。
    • discuz5 不是太喜欢discuz7的界面。discuz5(springside常用的那款界面)的界面感觉清爽些,但改了些后发现里面的html和css写的实在不怎么样。
    • fluxbb 目前打算用她的模板了。界面给人的感觉不错,html和css写得挺好。界面够简单,要套用模板应当不会太困难。
  3. 增强附件功能
    虽然pybb提供了附件的支持,但功能还是比较弱。
  4. 增加一个公共的个人信息模块
    pybb已提供了一个保存用户个人信息的功能,但通常这些信息会是整个工程所共享的。我觉得这些信息还是单独放到一个专有的app里比较好。这个app可以以代码的方式包括的工程里,需要增加个人信息的时候直接修改model代码。

后记

最后还是选择了完全从头进行开发。pybb里面可以用的东西不多,而且他的开发思路和我还是有些分歧。

url_helper简化Django的url配置

django的url采用正则表达式进行配置,虽然强大却也广为诟病。反对者们认为django的url配置过于繁琐,且不支持默认的路由功能。

我倒觉得还好,只是如果觉得不爽,为什么不自己小小的hack一下,反正也就几行代码的事。

在这个背景下,我整了这个url_helper,利用url_helper可以简化配置和实现url的默认路由。所谓的url_helper其实就只有url_helper.py一个文件,使用的时候只想要import就可以。

url_helper的具体用法请参考具体的例子:

url_helper下载/范例

下面对使用方法做个简单的说明。

url的默认路由

from url_helper import execute, url_
import views
urlpatterns += patterns('',
    url(r'^(?P.*)', execute, {'views': views}),
)

在urls.py里增加如下配置,其中views为需要进行路由的views模块。url的规则为 /action/param1/param2/…/ 。

例如:

#/edit/4/
def edit(request, n="id"):
    html = """ edit object: %s""" % n
    return HttpResponse(html)

在没有指定action的时候默认使用的action为index。

提供函数url_简化url配置

仿照ROR的做法,参数用”:”标识。

例如:

url_(r’/space/:username/:tag/’, views.url_), 对应的django url配置为url(r’^space/(?P<username>[^/]+)/(?P<tag>[^/]+)/$’, views.url_),

#url_(r’/space/:username/:tag/’, views.url_),
#/space/vicalloy/just/
def url_(request, username, tag):
    html = """ username: %s 
tag: %s""" % (username, tag) return HttpResponse(html)

url_helper的完整代码

就如前面说的,代码非常少。不过实际应用的话,应当还需要做一些扩展。

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
from django import http
from django.conf.urls.defaults import url
import re
def execute(request, urls, views):
    """
    urls [methodName/]param1/param2/.../
    methodName default index
    """
    def get_method(views, methodName):
        try:
            return getattr(views, methodName)
        except Exception, e:
            return None
    method = None
    params = [e for e in urls.split("/") if e]
    params.reverse()
    if params:
        method = get_method(views, params.pop())
    if not method:
        method = get_method(views, 'index')
    if not method:
        raise http.Http404('The requested admin page does not exist.')
    return method(request, *params)
def url_(*args,**dic):
    regex = args[0]
    if regex[0] == "/":
        regex = regex[1:]
    regex = '^' + regex
    regex = regex + '$'
    regex = re.sub(":[^/]+",
            lambda matchobj: "(?P<%s>[^/]+)" % matchobj.group(0)[1:],
            regex)
    return url(regex, *args[1:], **dic)