将django的models放到多个文件中

 

随着django程序越来越大,一个application里的model也越来越多,而django有个非常不好的约定就是所有的model都写在一个models.py 文件中, 而对于喜欢追求“优雅”的程序员来说,这的确很难忍受。

由python的特性,自然会想到将models.py 用一个目录代替,在__init__.py 中,import整个目录里的文件,这样python是认可了,django却不认! ./manager.py syncdb 的时候并不会发现目录下面的model。

搜了半天,发现解决方法比较简单,只要在每个model类中加上Meta的app_label 属性就可以了。

from django.db import models

class Test(models.Model):
    class Meta:
        app_label = 'myapp'
但还是觉得这个地方有点别扭,总是要记着加上这个,显得不那么自然。
这种做法是没有在Django官方文档里说明的,之前还用过另外一个Undocumented Technique,是在Django Single注册的时候,

models.signals.post_save.connect(flaggedentry_post_save, sender=FlaggedEntry, dispatch_uid=’mofin.store.models’)

其中 dispatch_uid 是一个undocumented 参数,指定这个参数后,则对应的single 处理函数不会被重复注册,出现这种问题的情况是,当上面的注册语句被直接写在文件里,而这个文件又被import了多次,则上面的语句会被多次执行,如果没有指定 dispatch_uid 的话,处理函数就会被多次注册,而Single发生时就被执行多次了。

参考资料

几个 Django 第三方库/applications

 

Django evolution

执行 ./manage.py syncdb 的时候,django会查找新的model来创建数据库表,但当我们更新model的结构时(如增加字段),则需要手工修改对应数据表的结构。Django-evolution 正为解决这个问题而存在。

地址 http://code.google.com/p/django-evolution/

django-ratings

ratings是web2.0的基础元素之一,django自然不能缺少,个人估计它有望成为官方app

http://github.com/dcramer/django-ratings

django-tagging

tagging 是web2.0的另一个基础元素,这个库相当好用和强大。

http://code.google.com/p/django-tagging/

django-messaging

哈哈,还是web2的元素啦,这个是用户与用户之间的message系统,与django内置的message不是一回事,这个库比较简单。

http://code.google.com/p/django-messaging/

django-photologue

强大的图片处理、管理功能

地址 http://code.google.com/p/django-photologue/

django cms

一个基于django的CMS系统

地址 http://www.django-cms.org/

django-grappelli

你认为django的admin界面不够好看吗,看这个, 里面有漂亮的截图,相信你会喜欢。当然这个库也不仅仅是为了好看,它还有很多更方便的功能。

地址 http://code.google.com/p/django-grappelli/

django-filebrowser

这个库的作者就是上面的 django-grappelli 的作者,怎么样,别以为他只会做界面,看看这个,这是一个相当强大的文件管理系统,直接在admin里面就可以完成静态文件的上传和编辑。你还在用自己做的编辑系统吗,咳咳。

地址 http://code.google.com/p/django-filebrowser/

django-solr-search

solr是做中小型搜索的首选,可以说是易用与强大的完美统一,django当然不会放过。solr不是已经很简单了吗,是的,但为什么要拒绝更简单呢?这就是django的哲学,我不骗你,编码真的可以是一种享受…  当然啦,还是有点缺憾,solr内存使用有些大呀…,但这不要怪到django头上。

地址 http://code.google.com/p/django-solr-search/

django-avatar

这跟电影《阿凡达》可没有什么关系,如果你熟悉web开发,早就应该知道 avatar 的意思是指web上用户的头像。这个应用就帮助你的django站点方便的增加用户头像的功能。

地址 http://github.com/ericflo/django-avatar

django 1.2 alpha

 

备受期待的 django 1.2 release了它的alpha版,在这个版本中,有个重量级的更新,那就是多数据库的支持。

在以前的django版本中,只能支持一个数据库,还记得上次跟子轩讨论过如何连接多个数据的问题,当时的感受就是:框架,就是说有些东西是不能实现的…

现代化的web开发,几乎没有只使用一个数据库的,多数据库是一个系统可扩展性的重要方面,django 1.2 朝这个方向进了一步,也说明了django 打造工业级web框架的目标。

django 1.2 中还增强了安全性与 message系统,其message并不是用户间的message,而是系统对用户的一种提示信息,这类似于 ROR 中的flash。zendframework 中也有类似的东西,好像也叫什么什么flash,当时大家讨论zend的时候,有人以为是对adobe falsh的支持。 其实,国内的web应用并没有很流行地使用flash的概念,相关功能还多是通过应用逻辑来展示的,开发还不够工业化呀。

 

正是的release预计在3月中旬,到时候估计 Mapiz 正好可以用上,愿 Mapiz 与 django 还有我一起成长吧。

今天读到 阮一峰 写的 PHP很烂?我的看法,嘿嘿,其实也是俺的看法啦,在no-framwork framework: 让php找回最真 我曾试图表示一些对php的看法,但总觉得说不到点子上,今天看峰哥用简单的语言说清楚了深刻的道理,恩,果然是高手。

几个django相关的网站

Python 与 Django 的时区问题

在编码中牵扯到时间问题的时候,总是容易被时区问题搞混,一直以来,都是反复试验应付过去,今天终于搞清楚了个中缘由,一个心结也得以化解。

Python 的时区问题

  • datetime.today() / datetime.now()
    这两个函数获得的是当前的系统时间,但得到的datetime对象中的tzinfo是空的,即使系统中设置了时区。
  • datetime.utcnow()
    这个函数获得当前的utc时间,应该是根据当前系统时间和时区来计算的。
    例如系统时间为14:00,时区为 Asia/Shanghai (北京时间),utcnow返回时间为 6:00。同样,得到的对象中的tzinfo 为空。

环境变量 TZ 对以上函数的影响:
当系统中设置了环境变量 TZ 的时候,或者在python中设置了 os.environ[‘TZ’] 的时候,上面的函数获取的时间便是TZ对应时区的时间。其实这里可以认为 TZ 影响的不是这些函数,而是影响的系统时间,这可以从date命令的返回结果看出。datetime.now() 与 date命令返回的结果总是一致的。

Django的时区问题

明白了上面几个python中的函数,django的时区问题看起来就简单了。

在django的setting中,有一个设置是 TIME_ZONE, 来设置程序中使用的时区。

从django的文档中得知,TIME_ZONE的作用就是改变 os.environ[‘TZ’]  ,但改变os.environ[‘TZ’]  并不会改变系统环境变量 TZ , 因此,如果 TIME_ZONE 的设置于系统时区设置不一致,则在程序中 datetime.now() 获得的时间就与 date 命令的时间不一致了。

因此,TIME_ZONE 应该设置为程序希望使用的时区。对于一个本地的程序,TIME_ZONE 设置为与系统时区一样即可;而对于一个国际化的应用,TIME_ZONE 最好设置为UTC,在显示的时候再根据当前用户所在的时区做调整。