偶对django的rant

本文乃我半夜不爽的咆哮之作。django的忠实fans可无视本文。


久闻django大名，号称与ROR齐名。刚才就开始看hideto的《翻译www.djangobook.com系列》。然而一边看一边摇头，才看到第四章模板当中，我就看不下去了。

django的设计实在是太恶心了！

就我看的这几章已经暴露出的问题：

1. url要用正则匹配，这是很差的设计，完全罔顾url的最常见的匹配习惯就是按照 / 来划分的事实。诚然正则具有最大的灵活性，但是这种所谓灵活性在url匹配这个事例中完全是负担！仅就这一点设计而言，django就不配称快速开发框架。因为光光一个充斥^$好多括号的配置文件已经足够把人折腾死了。

2. 最简单的几个配置文件都要import。。。view里的request居然也要import。难道是python的限制？

3. 使用template要指定，难道没有默认约定吗？

3. 模板太奇怪。首先是{%，为什么不用<%？php,asp,jsp都用，django偏偏要独树一帜？那么独树一帜（比如velocity用#，比如xquery直接用 { } ），你干脆别用那可恶的%符号啊，{和%的组合莫名其妙不伦不类。

4. {%如果说纯粹是个人喜好问题，那么模板的功能限制就是实在的大问题。诚然，我赞同对模板加以限制的设计哲学。但是django的平衡点实在混乱。

只支持无参方法调用，但又加了silent_variable_failure和alters_data。事实是：方法是否可用于view，与有否参数无关（因为过滤器其实就是变相方法）。你要么就什么方法都不支持（像jsp一样），所以silent_variable_failure和alters_data这两个属性根本就是为了错误的设计决策打的patch！

不许if混用and / or，但是要求if嵌套？当模板作者都是白痴啊！

不许写 if a = b，偏要写ifequal a, b，我只能说设计者的脑子进水了！！

唯一值得庆幸的是，django总算允许使用其他的模板系统。（但是我疑惑有多少用户选择其他模板系统？）

关于django的模板哲学（引自hideto的译文）

“有些其它的模板语言是基于XML的
XML的格式容易输错，并且XML的模板解析速度也容易变得很慢而难以接受 ”

胡扯！xml格式容易输错吗？{%就不容易输错？！有无数的工具支持xml，无论ide或者简单的编辑器都支持xml。xml解析速度慢吗？完全胡说八道。

“Django模板系统没有设计成可以在Dreamweaver等WYSISYG编辑器中显示良好
这类编辑器有很多限制，Django希望模板作者直接编辑HTML时感到舒适 ”

虽然我也不喜欢WYSISYG编辑器，但是通过攻击WYSIWYG编辑器来给自己的设计不兼容此类编辑器找借口，我只能对设计者树中指！

“模板系统的作者意识到大部分Web页面的模板是页面设计者写的而不是Python程序员写的
他们不具备Python知识”

所以又要学一种新语言。而且这种语言又不像xml（因为xml容易输错解析慢），又不像asp/php/jsp（鬼知道什么原因），又不兼容wysiwyg编辑器（因为希望你直接编辑html时感到舒适！）……请问，这种模板是要给谁写的？python程序员？html程序员？js程序员？美工？没有一种人会喜欢它。特别是那些拼写equal也拼不清楚的人（操，我都要确认两遍是ifequal而不是ifequals，奶奶的，你就不会简写成ifeq吗？对了，还有一个狗屁的ifnotequal）

“模板不能设置和改变变量的值
可以通过自定义模板标签来达到这个目标，但是内置Django模板标签不允许这样做”

是的，我警告过你们了，改变值是邪恶的，其实你们最好回去用xslt模板，django模板只是xslt模板的拙劣的变形，为的是照顾你们这些被蛇般邪恶的py..——哦我是说c,java还有c#惯坏的可怜程序员们的智商。

另一方面，在给template传值的时候，倒可以使用locals()这样邪恶的函数。当然这是python的错，我相信要给django的设计者来选择，如果有可能的话，他一定不会让这么邪恶的事情发生！

……

原谅我用“恶心”两个字形容django，因为我没想到它是如此“独特”。如果不是标题是django，在阅读的时候我还以为这又是哪个山寨框架（参见JE最近热帖）呢！

我只是看了点文档就发觉了这些问题，其实这些问题django的用户不是没有感觉——因为我好奇如此拙劣的设计怎会没有人抱怨，所以我搜索了一下：


http://groups.google.com/group/python-cn/browse_thread/thread/c32a8ba1b2e1f5f3/56ad35cbc4dd21d9

一位django的曾经用户因为不堪忍受django而开始自制山寨框架 写道

至少从我个人角度来说，我是离django越来越远了，因为许多不满意的东西无法得到改善，只好另起炉灶了。许多东西django可以说做得还不错，但是仍然有 许多的问题，比如说：
社区的开放性。许多核心成员过分强调他们的哲学，造成他们无法听进去别人的意见，比如template的所谓简洁性就是一个例子。模板的简洁造成功能就有限制， 因此django的模板允许你使用tag。但这样一来造成tag本身就是另一种语言了，而且是由许许多多的人维护的语言。写一个tag我并不认为很轻松。与其如 此，不如直接引入python代码，象许多模板系统一样。用不用是用户的事，但有没有是框架的事。django小组对社区的建设也不尽人意。象ruby有仓库的 网站，不知道django现在有没有，这个问题也早就提过，但是至少从我不开始关注django的时候之前一直没有改善。这一点非常影响一个社区的发展。
过分看重admin功能，以至于把其它可以做得更好的地方给忽略了。比如ajax框架。再比如说自动模板对应，这在ruby,
web2py和uliweb中都有，可以非常简化。而django在做这个时候很简单，就是定义了一个render_to_response()，因此说dja ngo的复杂需要你记住许多的模块是如何被导入的，虽然有这些简化的方法，但仍然不够简单。再比如说urls.py，刚开始还是不错，但是后来发现，定义一个包 括了正则式的url还是挺麻烦的，远没有某些Route模块简单。
算了，不说了，各有所爱。
……
模板为什么会复杂，我认为更多是因为模板本身造成的。比如web2py的模板可以直接嵌入python代码，但是它的模板tag就那么几个，你认为它复杂吗？并 不是模板本向复杂，而是因为模板中的内容复杂。django模板的弱化，导致tag库盛行，但是tag写起来容易吗？它不也算是一个DSL的东西？与其如此还不 如直接使用python代码，至少我认为python代码比tag要简单多了。比如你做一个比较：
{% if var is None or a == b %}
不知道现在这个在django中是否可以支持，一个挺简单的比较，怎么就有好几个标签：if, ifequal,
ifnotequal。再去djangosnippets上看一看，为if做的扩展tag也有好多，我还写过一个pyif的tag，目的就是可以在django 模板中直接使用python表达式，这本来就是很简单的事，结果django给做复杂了。
……
举例来说：从一开始我就不喜欢那个DJANGO_SETTINGS_MODULE，真是麻烦死了，它甚至都不能有个缺省的判断。
http://code.djangoproject.com/ticket/824
在这个ticket我其实是想说当不存在时可以有一个缺省的判断。但是下面的回复却是告诉我在使用前应该设置一下。
http://code.djangoproject.com/ticket/904
在这个ticket下，有人给出一个缺省查找的补丁，但是被拒绝，应该是通过 django.conf.settings.configure()
来手工设定，还是很麻烦。
这只是一个例子。说明django在某些地方的独立性和智能化(或缺省设置)的处理上还不够。

可以看到，我刚才说的那几个问题他都提到了。我没提到的问题他也提到了（毕竟是受害者，我目前只是看客罢了）



我其实对于python社区的web框架抱有厚望，很多年以前zope就令我倾倒。可是等了那么多年，许多人推崇的django就是这么一个货色，实在令我大惑不解。也许是因为python社区以前没有足以与它竞争的框架。不过一般而言，如果不考虑平台（譬如GAE），那我前有ROR，后有Grails，怎么都不会选django这个货色。


附笑话一则：

引用

再举个例子，{#
#}和{%comment%}{%endcomment%}都是用来生成注释的，但是前者是不能有换行的，而后者可以任意。可以看出在django的模板中还区 分单行注释和多行注释。以前在邮件列表中就讨论过这件事，但是django团队不同意修改。好象理由就是象c/c++之类的语言有就单行与多行的区别，并且不一 样。麻烦不，用{##}多简单啊。为什么强调不引入过多的程序逻辑，但是到了注释却搞出个单行和多行。所谓的前端开发者谁管别的语言是怎么定义的，django 怎么定义就怎么用呗，这里真是没有必要。只是注释而已，也没有什么特殊的处理原因，还搞出那么多的tag。