随着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发生时就被执行多次了。

参考资料

• http://andrewwilkinson.wordpress.com/2009/01/20/placing-django-models-in-separate-files/
• http://blog.amber.org/2009/01/19/moving-django-models-into-their-own-module/

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 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的看法，但总觉得说不到点子上，今天看峰哥用简单的语言说清楚了深刻的道理，恩，果然是高手。

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，在显示的时候再根据当前用户所在的时区做调整。