看好 Django 和 Werkzeug
2009-05-13, Wednesday 14:29 PM
|
1
comment
0
pingbacks
开发框架的繁荣通常从侧面反映了这门编程语言的广泛接受程度, Java, C++, PHP 都各有不少开发框架.
Python 则是有过之而无不及 — Web Frameworks for Python, 这只是其中一部分, 还有很多其它大大小小的土制框架.
Python Web 开发框架的空前繁荣得益于 WSGI 和 PEP 333 规范, WSGI 定义了服务器/网关如何同 Web 应用 交换数据, 它还更进一步的明确了中间件的行为, 使中间件能够被复用. 下图用洋葱形象的描述了 WSGI 的请求处理 (来自 Pylons 文档) :
WSGI 规范让 Web 开发的各个要素自由组合成为可能, 利用各种现有的库装配出自己满意的 Web 框架也不是件太难的事情 — A Do-It-Yourself Framework.
Python 社区不断生产出新的 Web 框架, 快得让人窒息, 以致很多人, 包括我都曾希望挂掉几个. 后来想想这可能未必是件坏事, 虽然分散了社区资源, 但也利用了闲散的智力资源, 不同的框架之间可以也相互借鉴和给予灵感, 催生一个更开放, 更繁荣的社区.
Django
众多框架中, 个人感觉社区势头比较好的是 Django 和 Zope 系 (Zope3, Grok, Repoze.bfg). Pylons / Turbogears 等框架虽然灵活, 但并没有很好的解决复用问题. Django 的 app 复用机制和 Zope 系的组件机制是目前所有框架中最完整的方案.
除 Django 和 Zope 系之外的大部分框架, 各具特色的同时, 其实也都大同小异 — 都符合 WSGI 规范, 而且都没能很好的处理复用.
Django 很适合用来快速搭建在线社区, django-registration / django-profiles / pinax 等大量现成的 app 可以整合利用.
不过独立应用软件是 Django 的弱项, 比如类似 Wordpress / MoinMoin 这类软件.
Django 没有对普通用户提供特殊照顾, 所有的设施都是面向开发人员的. 我试过 Byteflow, 一个基于 Django 的 Blog 引擎, 部署方式还是过于原始, 非 Django 开发人员不容易搞定. Byteflow 虽然提供很多特性, 但易用性是最大的问题: 我不能在管理后台修改一些常用配置, 每次 Byteflow 更改配置都需要重启 Django 服务, 相比之下 Zine 易用的多, 插件和主题支持也比较完善.
WSGI + Werkzeug + Jinja2
如果 Django 不适合做一个小的应用或者独立应用软件的话, 谁更适合呢? 有很多不同的选择, 我倾向于 WSGI + Werkzeug + Jinja2, 和 Sphinx / Pygments 一样, Werkzeug 和 Jinja2 都出自 pocoo 团队.
Werkzeug 在德语里面是 “工具” 的意思, “Colubrid” 项目的后续, 不属于开发框架的范畴, 但它是相当成熟和完整的 WSGI 工具模块. 比较成功的独立应用软件如 Zine 和 MoinMoin 1.9 都是基于它. 和 Paste 一样, Werkzeug 可以用来整合不同的 WSGI 中间件, 搭建自己的私有平台或框架.
Jinja2 是 Jinja 的后续版本, 它和 Django 模板非常相似, 但是没有 Django 模板的种种限制, 比如不能调用函数, 不能使用 Python 语句等. Jinja2 的性能比 Jinja 有很大的提高, 作者的测试结果是仅次于 Mako.
很多人误认为 Jinja 模板系 “日货”, 并以为是指 靖国神社. 其实作者 Armin Ronacher 是奥地利人, 年纪不大, 却主导和参与了很多比较有影响的开源项目: http://lucumr.pocoo.org/projects/. 他经常使用 mitsuhiko (圆谷光彦) 这个 ID, 搞得我有段时间也以为他是日本人. Armin 好像会些日语, 可能对日本文化也是颇为神往.
英文中 Template (模板) 和 Temple (庙宇) 有相似的发音, 这位兄弟就联想到了日本的 Jinja (神社, 庙宇), 蛮有创意的. 不过一般的 神社 和伤害中国人民感情的 靖国神社 不是一码事.
