偶对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。

评论

15 楼 mubs 2009-04-08  

感同身受。我用django做过两个项目，一个网站，一个应用系统，做网站还算方便，做应用系统苦不堪言。如果说URL正则匹配还能忍受的话，那么那个form是我最不能忍受的东西，这明明就是struts里的form啊，照我看来django就是一个python版的struts。

14 楼 ahuaxuan 2009-04-07  

django的url
django的url确实有点麻烦，如果设计成zero-configuration就比较好了，我之前也这样做过，利用反射和命名组，可以让一个view中只需要一个url的配置，这样就成了有多少个views.py，就只需要多少行配置

 (r'(?P<method>[a-zA-Z0-9]+)^$', 'inforplatform.bargin.views.execute')）  

然后在views里加上这个方法：

def execute(request, method):  
     return getattr(mark.views, method)(request) 

通过以上这种做法，我们只需要配置一行代码，就搞定了views里的方法，但是这种方法的限制就是views里的其他方法不能再有除request职之外的参数了
-----------------------------------------------------------------------------------------------------
模板语法
对于django的模板，我觉得可以接受，模板的功能都是大同小异的，freemarker，velocity我都是一直在用的，差不了多少，如果从更高的层次上来看，它没有什么明显的优点，但是也没有什么明显的缺点，有点鸡肋的感觉，给人的感觉就是“无所谓”

-----------------------------------------------------------------------------------------------------

模板路径
模板的选择确实不怎么智能，最好是强制要求模板的命名，然后指定字符串就能找到对应的模板，加载之，正如codebehind一样，但是它为啥不这样做，应该是作者想法和我们不一样（俺们也不能要求作者遵循俺们的想法），但是这并不妨碍俺们能将其改造成codebehind那样，其实我们只要写个很简单的方法，根据规则手动拼模板路径就ok了，这个对应要使用coc的人来说不是难事

13 楼 Sam1860 2009-04-07  

http://web2py.com/examples/default/examples#template_examples

觉得web2py的template不错，虽然还是不兼容html，但基本就是python

12 楼 hax 2009-04-07  

引用

url要用正则匹配
个人感觉这是相当好的一个设计，尤其在实现URL的静态化时。而且Python的正则式支持命名分组，用起来相当爽。
不明白为什么大家对Django的模板如此多的批评，我感觉它设计很不错，尤其是模板的继承，很方便。

即使它支持命名分组，仍然是很糟糕。

对比：

urlpatterns = patterns('',  
    (r'^articles/(?P<year>\d{4})/$', views.year_archive),  
    (r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', views.month_archive),  
)  

static mappings = {
  "/$articles/$year/" (view:'year_archive') {
    constraints { year(matches:/\d{4}/) }
  }
  "/$articles/$year/$month" (view:'month_archive') {
    constraints {
      year(matches:/\d{4}/)
      month(matches:/\d{2}/)
    }
  }
}

显然grails的配置方式更直观，更容易维护。

命名组是为了缓解正则的复杂性，但是问题是，我们其实并不需要这个复杂性。

11 楼 闲云无心 2009-04-07  

个人还是那观点，django只适合做适合django做的，那么一切特点都是优点，如果强迫django做不适合它做的，那么一切特点都是掣肘，灵活性需求高一点的不如看看werkzeug之类的吧

10 楼 xiaopaozi 2009-04-07  

引用

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

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

这个用起来确实感觉很别扭。

引用

url要用正则匹配

个人感觉这是相当好的一个设计，尤其在实现URL的静态化时。而且Python的正则式支持命名分组，用起来相当爽。

不明白为什么大家对Django的模板如此多的批评，我感觉它设计很不错，尤其是模板的继承，很方便。

9 楼 zbird 2009-04-07  

robbin 写道

要直接在模板当中嵌入python代码，恐怕不太现实。python是强制使用tab缩进的，你在html模板片段里面嵌入python代码，本身html就缩进很多层了，这个时候你极难用肉眼保持住正确的python缩进层次（如果嵌入的python代码比较复杂的话）。

所以我的理解，不是django设计哲学的问题，实在是python缩进带来的限制，其实你观察一下，没有一个python web框架是直接拿python代码做模板语言的。

大多人想内嵌python代码，并不是想if什么都需要的（这些模板会内置支持）。
主要是想做一些表达式计算。
比如做类似s.split()，add(1,2)这样的操作。
对表达式的支持很多python的模板语言已经支持了，比如geshi、jinja（一个类似django模板的模板）。
MaKo更是存储的python语法。
当然，同python一样，这个模板也是要求缩进的。

8 楼 zbird 2009-04-07  

django是挺独断的一个框架，要不适应它所谓的哲学，要就用其他的了。
一个框架是不可能让所有用户满意的（那些想让人人都满意的框架大都挂了）。

此外不少觉得不适应的东西，自己稍微做点改动就可以了。
比如希望默认import某些东西，只想要创建一个对应的文件模板就可以了。
template的自动指定，自己对render_to_response再做个简单的包装就可以了。

7 楼 hax 2009-04-06  

mikeandmore 写道

推荐TG吧...

tg这个名字太sui了，君不见tgbus就被干掉了。

6 楼 mikeandmore 2009-04-06  

推荐TG吧...

5 楼 剑事 2009-04-04  

url是麻烦
模板 觉得 extend  bloack 不错

python里  感觉也没有比django更合适的用了

4 楼 hax 2009-04-04  

举个例子，每行交替显示的功能。在django模板中需要了解diviseby（靠，我拼对没有？我拼错了。。。但是你知道我意思）这个filter。然而如果是三行交替呢？如果是四行交替呢？如果有el，只要取模就可以了，这个divisibleby怎么搞？

可见divisibleby就是一个不成功的patch。而且对于非英语用户及其不友好。

3 楼 hax 2009-04-04  

我认为缩进不是问题。过去在页面中嵌入java/vbscript/php的人，也都保持有某种缩进格式习惯，只不过各人各样，没有强制。

缩进其实是为了程序逻辑块。如果内置的逻辑标签（比如JSTL）足够，就不用在代码中缩进了。我其实也反对在模板中嵌入大段程序逻辑。问题是django的模板内置功能太弱。开发者需要某种形式的EL，这种EL显然最好利用开发者已有的知识，例如JSP EL像简化的java或者javascript。也完全可以对python做一个裁剪，做一个python el。正如jsp el没有跨行的，python el也可以完全不受缩进的困扰。

BTW，我承认filter是个不错的东西，但是没有好到足以替代某种EL。特别是在需要处理表现逻辑的时候。不是所有逻辑都是业务逻辑，也不是所有表现逻辑都简单到可以转换为一串filter。filter就是smarty的modifer，但是smarty至少默认可以使用所有php内置函数作为modifier。要理解filter和灵活组合运用filter，一样需要学习成本，如果一个程序员不能很快的理解如何使用filter，没有理由写模板的人（我就搞不清楚django的模板的目标用户是谁？）就能很快理解。

还有改变值，我也认为理论上模板不应该改变值，但是仅限于与view无关的部分。为什么view自己的逻辑不能有临时变量？xslt好歹还能声明varaiable（接近常量），django连这也不行（也许行，但我在文档里没发现）。

2 楼 robbin 2009-04-04  

要直接在模板当中嵌入python代码，恐怕不太现实。python是强制使用tab缩进的，你在html模板片段里面嵌入python代码，本身html就缩进很多层了，这个时候你极难用肉眼保持住正确的python缩进层次（如果嵌入的python代码比较复杂的话）。

所以我的理解，不是django设计哲学的问题，实在是python缩进带来的限制，其实你观察一下，没有一个python web框架是直接拿python代码做模板语言的。

1 楼 jjx 2009-04-04  

1. url 就我实际做项目中，感觉灵活性很高，初学者可能会感觉有点烦

2. 模板这个问题，估计现在要改已经是相当困难，成型了嘛。 不过在django中使用其它模板是非常简单的，你不喜欢可以使用mako ,jinja2之类的。django模板这样设计，也不是没有好处的。最起码在django的模板中，你不会看到复杂的逻辑，这其实就是它的目标