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




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



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


附笑话一则：

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

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

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

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

我认为缩进不是问题。过去在页面中嵌入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连这也不行（也许行，但我在文档里没发现）。

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

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

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

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

推荐TG吧...

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

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

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

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