听一个turbogears的家伙讲django该向zope学什么
潘俊勇
不过在zope是轩然大波。从前一直没空去认真听英文，今天偶然翻阅，讲的的确很深刻。
django已经越来越复杂，有些地方在开始犯zope曾经犯过的错误。一个良好的产品开发的指导思想会对产品发展非常有益。一个开放的社区，才是一个
长远发展的社区。
这个演讲是跨越多个框架的，对这些框架理解也非常深刻。非常推荐大家听听，以后聚会的时候可以交流下。
（同时，我更坚信wsgi路线是最终路线，paste社区和repoze社区比较钟情）
Jiahua Huang
> 这个是在django打会上的一个主题演讲，不知道在django社区有多大的影响。
>
> http://www.youtube.com/swf/l.swf?swf=http%3A//s.ytimg.com/yt/swf/cps-vfl70443.swf&video_id=fipFKyW2FA4&rel=0&showsearch=1&eurl=&iurl=http%3A//i3.ytimg.com/vi/fipFKyW2FA4/hqdefault.jpg&sk=OwEE9yYljq5SNG-UhcfuRk1eoXiFiFX6C&use_get_video_info=1&load_modules=1&egm=0
>
赞潘老大～～～
limodou
至少从我个人角度来说，我是离django越来越远了，因为许多不满意的东西无法得到改善，只好另起炉灶了。许多东西django可以说做得还不错，但是仍然有许多的问题，比如说：
社区的开放性。许多核心成员过分强调他们的哲学，造成他们无法听进去别人的意见，比如template的所谓简洁性就是一个例子。模板的简洁造成功能就有限制，因此django的模板允许你使用tag。但这样一来造成tag本身就是另一种语言了，而且是由许许多多的人维护的语言。写一个tag我并不认为很轻松。与其如此，不如直接引入python代码，象许多模板系统一样。用不用是用户的事，但有没有是框架的事。django小组对社区的建设也不尽人意。象ruby有仓库的网站，不知道django现在有没有，这个问题也早就提过，但是至少从我不开始关注django的时候之前一直没有改善。这一点非常影响一个社区的发展。
过分看重admin功能，以至于把其它可以做得更好的地方给忽略了。比如ajax框架。再比如说自动模板对应，这在ruby,
web2py和uliweb中都有，可以非常简化。而django在做这个时候很简单，就是定义了一个render_to_response()，因此说django的复杂需要你记住许多的模块是如何被导入的，虽然有这些简化的方法，但仍然不够简单。再比如说urls.py，刚开始还是不错，但是后来发现，定义一个包括了正则式的url还是挺麻烦的，远没有某些Route模块简单。
算了，不说了，各有所爱。因为远离，所以django只能关注下了。
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: (new)http://http://hi.baidu.com/limodou
(old)http://www.donews.net/limodou
Zoom.Quiet
连接Youtube 太累，，，E文也差，谁给个文字版本的，大家共同研究哪，，
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Usage OOo to replace M$ Office; You can get the truely Freedom 4 software.
Elias Soong
fipFKyW2FA4 ？
潘俊勇 写道:
----------------------------------------
Personal Site: http://www.elias.cn
----------------------------------------
leopay
老潘给的地址弄不开。是否就是这个视频http://www.youtube.com/watch?v=
fipFKyW2FA4 ？
潘俊勇
子，我觉得不错的。
很多想法，和pylons之类，其实是相近的，简单是法宝。
不过，可以说，从limodou的经验看来，直到django，整个python社区，web框架的终结者仍然没有出现！
群雄分割，仍然在期待英雄一统天下。
而我看好bfg.
前不久，我是推了几次repoze.bfg，我是只炸雷不下雨，估计快成人见人恨的忽悠专家了。
上周四到金山做了一次商务拜访，和zoomq聊天，zoomq也建议我该动真格的。这个，的确是我没做好，汗
所以，周末我是认真跑起来了bfg。对于zope老人，bfg上手和理解是轻车熟路了。
研究下来，一句话，bfg也是想把zope忘简单里整，往开放里整，往人见人爱里面整。同时很方便组装成超级大炮。
zope的很多特性，我相信，是超过其他框架的。只是因为zope的封闭，而不为所知，bfg解决了这个问题。
我准备化些力气在bfg上，有些更实际的东西出来后，我再和大家分享。
On 12月20日, 下午10时12分, limodou <limo...@gmail.com> wrote:
> 2008/12/20 潘俊勇 <panjuny...@gmail.com>:
>
> > 这个是在django打会上的一个主题演讲，不知道在django社区有多大的影响。
>
> >http://www.youtube.com/swf/l.swf?swf=http%3A//s.ytimg.com/yt/swf/cps-...
vicalloy
> 2008/12/20 潘俊勇 <panju...@gmail.com>:
>> 这个是在django打会上的一个主题演讲，不知道在django社区有多大的影响。
>>
>> http://www.youtube.com/swf/l.swf?swf=http%3A//s.ytimg.com/yt/swf/cps-vfl70443.swf&video_id=fipFKyW2FA4&rel=0&showsearch=1&eurl=&iurl=http%3A//i3.ytimg.com/vi/fipFKyW2FA4/hqdefault.jpg&sk=OwEE9yYljq5SNG-UhcfuRk1eoXiFiFX6C&use_get_video_info=1&load_modules=1&egm=0
>>
>> 不过在zope是轩然大波。从前一直没空去认真听英文，今天偶然翻阅，讲的的确很深刻。
>>
>> django已经越来越复杂，有些地方在开始犯zope曾经犯过的错误。一个良好的产品开发的指导思想会对产品发展非常有益。一个开放的社区，才是一个
>> 长远发展的社区。
>>
>> 这个演讲是跨越多个框架的，对这些框架理解也非常深刻。非常推荐大家听听，以后聚会的时候可以交流下。
>>
>> （同时，我更坚信wsgi路线是最终路线，paste社区和repoze社区比较钟情）
>>
>
> 至少从我个人角度来说，我是离django越来越远了，因为许多不满意的东西无法得到改善，只好另起炉灶了。许多东西django可以说做得还不错，但是仍然有许多的问题，比如说：
>
> 社区的开放性。许多核心成员过分强调他们的哲学，造成他们无法听进去别人的意见，比如template的所谓简洁性就是一个例子。模板的简洁造成功能就有限制，因此django的模板允许你使用tag。但这样一来造成tag本身就是另一种语言了，而且是由许许多多的人维护的语言。写一个tag我并不认为很轻松。与其如此，不如直接引入python代码，象许多模板系统一样。用不用是用户的事，但有没有是框架的事。django小组对社区的建设也不尽人意。象ruby有仓库的网站，不知道django现在有没有，这个问题也早就提过，但是至少从我不开始关注django的时候之前一直没有改善。这一点非常影响一个社区的发展。
>
> 过分看重admin功能，以至于把其它可以做得更好的地方给忽略了。比如ajax框架。再比如说自动模板对应，这在ruby,
> web2py和uliweb中都有，可以非常简化。而django在做这个时候很简单，就是定义了一个render_to_response()，因此说django的复杂需要你记住许多的模块是如何被导入的，虽然有这些简化的方法，但仍然不够简单。再比如说urls.py，刚开始还是不错，但是后来发现，定义一个包括了正则式的url还是挺麻烦的，远没有某些Route模块简单。
>
> 算了，不说了，各有所爱。因为远离，所以django只能关注下了。
前些天还看到建议不要使用easy_install的言论。
理由是python的哲学是做什么都需要用户明确的知道。
easy_install就这么一条命令，都不知道在背后做了啥。
Jiahua Huang
> 前些天还看到建议不要使用easy_install的言论。
> 理由是python的哲学是做什么都需要用户明确的知道。
> easy_install就这么一条命令，都不知道在背后做了啥。
>
前些天这儿也说了不要用 easy_install，
可理由不是啥哲学，
而是 pypi 上好些包的质量太差。
limodou
> 之前就看过limodou兄的uliweb框架，很新很fasion，特别是对gae的支持，以及向paste/wsgi靠拢，而且在避免重复制造轮
> 子，我觉得不错的。
> 很多想法，和pylons之类，其实是相近的，简单是法宝。
>
> 不过，可以说，从limodou的经验看来，直到django，整个python社区，web框架的终结者仍然没有出现！
> 群雄分割，仍然在期待英雄一统天下。
>
> 而我看好bfg.
>
> 前不久，我是推了几次repoze.bfg，我是只炸雷不下雨，估计快成人见人恨的忽悠专家了。
> 上周四到金山做了一次商务拜访，和zoomq聊天，zoomq也建议我该动真格的。这个，的确是我没做好，汗
>
> 所以，周末我是认真跑起来了bfg。对于zope老人，bfg上手和理解是轻车熟路了。
>
> 研究下来，一句话，bfg也是想把zope忘简单里整，往开放里整，往人见人爱里面整。同时很方便组装成超级大炮。
>
> zope的很多特性，我相信，是超过其他框架的。只是因为zope的封闭，而不为所知，bfg解决了这个问题。
>
> 我准备化些力气在bfg上，有些更实际的东西出来后，我再和大家分享。
>
终结者我认为很难实现。就象java不也有非常多的框架吗？因为人们理解问题和解释问题的方式和习惯不同，虽然条条大路通罗马，但是如何达到各有不同。一个框架在越做越深之后，要么它可能是非常灵活，但是你需要先进行搭配，象pylons，要么相对固化，象django。各有各的好处。每一种哲学看上去都不错都挺合理的，这本身就说明就框架本身来说可能必然出现多样性。只不过对于某个用户来说，如果让他更方便进行搭建，如何让他更容易形成自已的开发模式我认为是一个重要的问题。
现在许多时候，我们都认为python适合进行快速开发，但是这种快速更多是体现在对变化应对的快速。但是变化之前需要你已经实现了一部分工作，并且已经形成自已的开发模式。因此象pylons还是django，我们在实际做的工作中不会说只满足于框架所提供的功能，它们的功能只是一个基础，我们需要在此基础之上形成自已的开发库，开发模式等，这是一个积累的过程，然后我们才敢说，用XXX框架我可以开发得很快，就是因为我们已经有许多东西可以复用了。
django的app思想不错(uliweb中也借鉴了)，但是在以前的邮件中也讨论过，它做得还不够，还可以做得更好。比如你要复用一个app，你需要做哪些工作？
1. 拷贝代码
2. 查看有哪些相关的静态文件需要同时拷贝
3. url的移植
4. 配置信息的处理
而目前django的方式让你基本上都是手工来操作，的确非常麻烦。因此我认为django过分在admin上下了功夫，但是在这些如何提高开发效率的方面django还需要改进。
limodou
先用着再说吧。我现在倒是对easy_install很感兴趣，因为前阵子在配置trac时就看到它的某些插件通过setup.py安装就可以被trac发现，我认为这一点很不错。easy_install可以先做为尝试，等以后有更好的可以替换。于是我也想能不能在uliweb中也实现app通过简单的安装就可以被发现。
taotao
On 12月20日, 下午9时55分, 潘俊勇 <panjuny...@gmail.com> wrote:
> 这个是在django打会上的一个主题演讲，不知道在django社区有多大的影响。
>
> http://www.youtube.com/swf/l.swf?swf=http%3A//s.ytimg.com/yt/swf/cps-...
taotao
taotao
On 12月20日, 下午10时12分, limodou <limo...@gmail.com> wrote:
> 2008/12/20 潘俊勇 <panjuny...@gmail.com>:
>
> > 这个是在django打会上的一个主题演讲，不知道在django社区有多大的影响。
>
> >http://www.youtube.com/swf/l.swf?swf=http%3A//s.ytimg.com/yt/swf/cps-...
>
Robert Chen
--
Robert
关注Python 关注搜索
Dynamic Life——http://blog.csdn.net/balabalamerobert
Leo Jay
> 我也觉的模板是最大的问题，虽然django社区的想法是想隔离代码。
>
我认为，模板的存在不是为了隔离代码，而是隔离表现与逻辑。
当一个template越来越复杂，复杂到自成一门语言，复杂到能处理很多逻辑的时候，我就感觉它已经背离了template的初衷了。
如果是这样，那为什么我要把这些东西分开，还要另学一门template语言？直接全写在view里就好了。
--
Best Regards,
Leo Jay
leopay
limodou
> 2008/12/21 taotao <tao...@gmail.com>:
>> 我也觉的模板是最大的问题，虽然django社区的想法是想隔离代码。
>>
>
> 我认为，模板的存在不是为了隔离代码，而是隔离表现与逻辑。
> 当一个template越来越复杂，复杂到自成一门语言，复杂到能处理很多逻辑的时候，我就感觉它已经背离了template的初衷了。
> 如果是这样，那为什么我要把这些东西分开，还要另学一门template语言？直接全写在view里就好了。
>
我想模板的作用主要就是把固定的和动态的可以分离，至于隔离表现与逻辑我不认为表现中就没有逻辑。现在大量的ajax的引入，人们追求越来越易用的交互，这些也使得前端的界面开发越来越复杂。所以从应用逻辑的角度我认为可以分为页面或前端和后台。现有的许多模板还是按照传统的cgi的方式，由后台返回页面，用户在浏览器输入，然后再提交。但是越来越多的处理开始集中于前端，甚至直接通过ajax就做了，其本上不需要后端的处理，前后端实现的分离。这个时候我们如何看待模板？
模板为什么会复杂，我认为更多是因为模板本身造成的。比如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中view从名字上看，它就是用来处理显示的内容。正因为它不是标准的MVC的结构，但是大家却从以MVC的标准来要求，所以才会有template和view分离。在我看来，可以认为它们就是一个东西。模板不过是view的一个简化处理。
limodou
> 对滴，模板要简单，可以直接让做页面的前端人员写。
让前端人员来直接操作模板不过是一种分工不同。并不是说只能前端人员才能操作模板。正如我前面所说模板怎么用是用户的事，但是功能不具备就是模板的事。在模板中增加逻辑并不是件可怕的事，这么多模板系统都支持嵌入python代码，象php这种直接就是混合的，不管怎么样，它就是第一位，这也说明了一些问题。
v cc
对于Django的模板，我觉得挺适合我们的团队的，模板将Python代码扔出去很对我的胃口，因为一旦Django提供嵌入Python代码，你很难强制要求程序员不使用，这个很难不是说你开不了口，而是你再三强调依然会有人不理睬。很简单，人总是自私的，总想按最满足自己利益的方式工作，如今Django不提供嵌入Python代码，都会有强烈的需求要求提供这种功能，一旦提供这种功能，怎么可能想象能限制使用呢？譬如一个人只在模板中20%的地方使用了Python代码，你是强制他改过来？还是容忍呢？强制他改过来，他可能会觉得你吹毛求疵，以我的经验，在国内，程序员都是骄傲的，谁都觉得自己的实现方式那就是最恰当的，虚心的程序员，有，太少；如果容忍，那就会有人在模板中开始使用30%，40%的Python代码。你总不能因为一个人在模板中使用了Python代码扣人家工资吧。所以，与其将公司的管理资源放在这些地方，不如你压根就不要提供这种功能，没有选择也就没有诱惑。我不知道大家使用Django，都是个人单枪匹马还是在一个团队中使用，这个团队都是精英人士，还是很多资质平庸的普通程序员，换个角度，你可能会发现得出的结果会有不同。另外，我有一个疑问很好奇，大家眼中，怎样的社区才叫"开放的"社区呢？
很显然，所谓的"开放的"社区就是贡献的代码大家都可以用，而不单单只是django用。因为django越来越流行，很多app就直接按django的模式做了，造成其他的框架很难复用这些app，压缩了其他框架的生存空间，也对资源造成一定的浪费，这确实是一个值得注意的问题。
关于模板，django这样作有莫大的好处，因为与其在模板里写代码，还不如在外面写。注意，这不是写另外一个模板语言，这是python语言！说到重用，这也是重用的最高境界，就是你每行代码都可以重用（因为你不能在模板里写代码，所以你必须在外面定义成Python
的函数，这样每个都可以重用）
vcc
_
我的django相关的的东东：
http://djangobook.py3k.cn
http://code.google.com/p/django-pyodbc
limodou
> 对于Django的模板，我觉得挺适合我们的团队的，模板将Python代码扔出去很对我的胃口，因为一旦Django提供嵌入Python代码，你很难强制要求程序员不使用，这个很难不是说你开不了口，而是你再三强调依然会有人不理睬。很简单，人总是自私的，总想按最满足自己利益的方式工作，如今Django不提供嵌入Python代码，都会有强烈的需求要求提供这种功能，一旦提供这种功能，怎么可能想象能限制使用呢？
> 譬如一个人只在模板中20%的地方使用了Python代码，你是强制他改过来？还是容忍呢？强制他改过来，他可能会觉得你吹毛求疵，以我的经验，在国内，程序员都是骄傲的，谁都觉得自己的实现方式那就是最恰当的，虚心的程序员，有，太少；如果容忍，那就会有人在模板中开始使用30%，40%的Python代码。你总不能因为一个人在模板中使用了Python代码扣人家工资吧。所以，与其将公司的管理资源放在这些地方，不如你压根就不要提供这种功能，没有选择也就没有诱惑。
> 我不知道大家使用Django，都是个人单枪匹马还是在一个团队中使用，这个团队都是精英人士，还是很多资质平庸的普通程序员，换个角度，你可能会发现得出的结果会有不同。
> 另外，我有一个疑问很好奇，大家眼中，怎样的社区才叫"开放的"社区呢？
>
使用python做开发，你不可能象java一样去要求。python的特性让程序员有很大的发展潜力，是限制还是鼓励，我想这是一个管理上要考虑的。就个人感觉，python团队基本上是少而精型的，更需要成员的创造力。
你不让他在模板中使用代码，那好，写tag算不算，如果这也不让，那都放在view中好了。view中有许多与展示相关的东西算不算逻辑与显示分离。在其它的回复中我认为django的view与template本来就是结合在一起的，它不是MVC，而是MTV。但实现上这个view是什么都干的。
limodou
如果真是逻辑的部分我认为无可厚非，但实际上许多在模板中的代码就是显示的处理，但因为模块不支持复杂的处理，所以不复不写在view中或tag中。而这些可能就是与这个模板密切相关的东西，放在一起我认为反而更有价值。
zhao shichen
Robert Chen
使用python做开发，你不可能象java一样去要求。python的特性让程序员有很大的发展潜力，是限制还是鼓励，我想这是一个管理上要考虑的。就个人感觉，python团队基本上是少而精型的，更需要成员的创造力。
你不让他在模板中使用代码，那好，写tag算不算，如果这也不让，那都放在view中好了。view中有许多与展示相关的东西算不算逻辑与显示分离。在其它的回复中我认为django的view与template本来就是结合在一起的，它不是MVC，而是MTV。但实现上这个view是什么都干的。
Robert Chen
limodou
一个东西的设计不是以敲出代码多少来计算的，perl的代码不是很少吗？你已经学会了python，还需要再去学不同的tag语法，这本身就是很奇怪的事。就直接拿django模板本身来说，不支持的功能可以举出很多，而且这些还只涉及到如何表示逻辑，而不是为了要实现所谓的分离，比如
if 是一个最明显的例子，elif 目前应该还是不支持吧。我曾经试图解决这一问题
http://code.djangoproject.com/ticket/3090,
这个问题还是由于django模板在解析时不处理结束tag的内容引起的，这其实就是一个设计的问题。再比如，如何简单地在模板中赋值，如何对它进行加工。在for中无法支持range之类的函数。这些不足并不直接与显示与逻辑分离相关，反而是本身功能是否完备的问题。所以也造成一个简单的功能都会出来许多的tag来处理，这是好事情吗？我不这么认为。template不支持python语法是一方面，但是你的功能也尽可能完整吧。
就目前来看我不认为招python程序员会造成成本下降。python还不足以同java, c++相竟争。反而会造成成本上升。个人观点。
显示逻辑应该在哪里处理，这本身就是一个问题。比如我要显示一个table，那么我有许多的数据。现在有几种做法：
1. 在view中生成table的html代码，然后在模板中直接使用。这种方式可以考虑，它的好处是我可以通过python直接生成html代码，减少了template的复杂性。但是如果你的table某一天改为了其它的显示方式，你要改的不是模板，而是代码。为了显示而修改代码，不知道这是大家所期望的吗？
2. 所以我认为也许合理的是view中只传出数据，然后在template中进行显示。那么在template中必然有循环，对数据进行加工这种简单的处理，这必然增加了模板了复杂性，但是实现了数据与显示的分离，我宁肯接受这种方式。
3. view还是传数据，但是数据是在tag中完成的，这样你需要开发一个新的tag，然后在模块中load它。那么与这种方式可以相比较的可以是这样：
{% import my %}
{% my.process(data) %}
既不用写tag语法，也能很方便地通用，也没有增加更多的内容，因为怎么处理都封装在函数中了。
所以从上面的分析，django的方式限制太多，引入了太多djangoic的东西，比如tag的复用。采用函数方式可以很方便的复杂，而tag只能在django中用。想复用可以，把代码拷贝出来改一改吧。
过分的封装反而会造成通用性差，复杂的问题，还不如简化一下。
至于php被诟病具体原因不好说，但我认为并不一定是展示与处理混合造成的，php只一样可以使用模板，更多的应该是管理上。但是无论如何，仍然有许许多多的php的东西做得还是不错。关键是使用的人，语言本身只是其中一方面。
张沈鹏
mako不能自定义标签 也有点不爽 有空去看看源码 怎么自己加标签:)
@@
2008/12/21 leopay <leo...@gmail.com>:
> 对滴，模板要简单，可以直接让做页面的前端人员写。
让前端人员来直接操作模板不过是一种分工不同。并不是说只能前端人员才能操作模板。正如我前面所说模板怎么用是用户的事，但是功能不具备就是模板的事。在模板中增加逻辑并不是件可怕的事，这么多模板系统都支持嵌入python代码，象php这种直接就是混合的，不管怎么样，它就是第一位，这也说明了一些问题。
闲云无心
jinja这类，性能不差又不厚实的，更像smartTemplate
感觉django的应用还是个定位问题，如果做个人BLOG，类cms站，类文章站或者商品展示交易站以及这类型站点的衍生，django肯定是利器
但是类sns站或者论坛，数据库结构复杂一点，需要大量的composite (primary) key，需要冗余，对pgsql或者mysql的
innodb需求不高，对动态片段缓存的需求大于静态缓存，模板渲染要求多一点，展现和后台应用灵活一点，django未必是个很好的选择
最末。。以上纯属一家之言。。。
On 12月21日, 下午3时14分, "@@" <ask...@gmail.com> wrote:
> 2008/12/21 limodou <limo...@gmail.com>
Zoom.Quiet
Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
但是，这样对UI的要求可就有些变态了，，，
以上，片段想法，，，
2008/12/21 闲云无心 <6743...@163.com>:
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
多吃菜,少喝酒;听老婆的话,跟党走!
limodou
> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
>
> 如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
> 模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
> 但是，这样对UI的要求可就有些变态了，，，
是的，不过这样的处理框架基本上只处理数据，不生成界面了。模板的作用就不大了。现在许多方式是在html中无害地嵌入js，这样也对减少直接在template中生成展示，而是交于js来生成，对于前端开发人员的要求需要掌握ajax之类的开发。要求也并不低。当你的开发方式在变化时，对模板的要求也会有所不同。但无论如何，我希望template可以支持python，这样我可以直接使用python去生成一些css,
html, js的封装，而且可以方便地使用它们，而不需要：1. 在view中处理展示 或 2.
需要生成象tag这样的东西，再搞一套语法去使用，直接pythonic多好。
>
> 以上，片段想法，，，
Zoom.Quiet
> 2008/12/21 Zoom. Quiet <zoom....@gmail.com>:
>> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
>> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
>> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
>> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>
> 和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
>
> 在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
> 核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
>
>>
>> 如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
>> 模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
>> 但是，这样对UI的要求可就有些变态了，，，
>
> 是的，不过这样的处理框架基本上只处理数据，不生成界面了。模板的作用就不大了。现在许多方式是在html中无害地嵌入js，这样也对减少直接在template中生成展示，而是交于js来生成，对于前端开发人员的要求需要掌握ajax之类的开发。要求也并不低。当你的开发方式在变化时，对模板的要求也会有所不同。但无论如何，我希望template可以支持python，这样我可以直接使用python去生成一些css,
> html, js的封装，而且可以方便地使用它们，而不需要：1. 在view中处理展示 或 2.
> 需要生成象tag这样的东西，再搞一套语法去使用，直接pythonic多好。
>
貌似 PyPy 就是这个路子？
可以用 Python 生成 JS/CSS 那么，，，，
另外，在 Zope 中也给出了一个道路，，，KSS,,,
>>
>> 以上，片段想法，，，
KSS, Ajax with style — KSS (Kinetic Style Sheets)
http://kssproject.org/
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)
limodou
> 2008/12/21 limodou <lim...@gmail.com>:
>> 2008/12/21 Zoom. Quiet <zoom....@gmail.com>:
>>> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
>>> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
>>> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
>>> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>>
>> 和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
>>
>> 在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
>> 核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
>>
>>>
>>> 如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
>>> 模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
>>> 但是，这样对UI的要求可就有些变态了，，，
>>
>> 是的，不过这样的处理框架基本上只处理数据，不生成界面了。模板的作用就不大了。现在许多方式是在html中无害地嵌入js，这样也对减少直接在template中生成展示，而是交于js来生成，对于前端开发人员的要求需要掌握ajax之类的开发。要求也并不低。当你的开发方式在变化时，对模板的要求也会有所不同。但无论如何，我希望template可以支持python，这样我可以直接使用python去生成一些css,
>> html, js的封装，而且可以方便地使用它们，而不需要：1. 在view中处理展示 或 2.
>> 需要生成象tag这样的东西，再搞一套语法去使用，直接pythonic多好。
>>
>
> 貌似 PyPy 就是这个路子？
> 可以用 Python 生成 JS/CSS 那么，，，，
>
不知道，不过这种语言转义的例子象GWT，有人喜欢，有人不喜欢。不知道使用者如何。但是这样一来它将把开发人员限制在这套API之上，从而让你不能直接接触到web开发最原始的东西。也许未来就是一种趋势吧。那样的所以东西都是java或python的东西，更不用分出彼此了。
> 另外，在 Zope 中也给出了一个道路，，，KSS,,,
没研究过啊。
Elias Soong
limodou 写道:
> 2008/12/21 Zoom. Quiet <zoom....@gmail.com>:
>> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
>> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
>> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
>> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>
> 和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
>
> 在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
> 核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
听了这个说法，我开始怀疑Django是否超出了最初用于文章管理系统的路子、打算
演化成更为通用的Web框架。。
>
>> 如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
>> 模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
>> 但是，这样对UI的要求可就有些变态了，，，
>
> 是的，不过这样的处理框架基本上只处理数据，不生成界面了。模板的作用就不大了。现在许多方式是在html中无害地嵌入js，这样也对减少直接在template中生成展示，而是交于js来生成，对于前端开发人员的要求需要掌握ajax之类的开发。要求也并不低。当你的开发方式在变化时，对模板的要求也会有所不同。但无论如何，我希望template可以支持python，这样我可以直接使用python去生成一些css,
> html, js的封装，而且可以方便地使用它们，而不需要：1. 在view中处理展示 或 2.
> 需要生成象tag这样的东西，再搞一套语法去使用，直接pythonic多好。
>
>> 以上，片段想法，，，
>
--
----------------------------------------
Personal Site: http://www.elias.cn
----------------------------------------
limodou
>
>
> limodou 写道:
>> 2008/12/21 Zoom. Quiet <zoom....@gmail.com>:
>>> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
>>> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
>>> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
>>> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>>
>> 和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
>>
>> 在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
>> 核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
>
> 听了这个说法，我开始怀疑Django是否超出了最初用于文章管理系统的路子、打算
> 演化成更为通用的Web框架。。
>
难道不是吗？
Elias Soong
limodou 写道:
> 2008/12/21 Elias Soong <elias...@gmail.com>:
>>
>> limodou 写道:
>>> 2008/12/21 Zoom. Quiet <zoom....@gmail.com>:
>>>> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
>>>> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
>>>> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
>>>> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>>> 和xml没关系。是看你自个再搞一套模板语法还是直接使用python。最关键的是我认为django的模板从语法上功能不全，用起来很麻烦。至于展示与逻辑分离这可以算是第二个问题。这个讨论的意义不大。当然我的整个意思是：
>>>
>>> 在某些功能上不完整影响了使用，也就是易用性差，django也在越来越复杂。
>>> 核心团队的关注点应该多从提高用户的参与，复用，提高生产率上下功夫。
>> 听了这个说法，我开始怀疑Django是否超出了最初用于文章管理系统的路子、打算
>> 演化成更为通用的Web框架。。
>>
>
> 难道不是吗？
>
jinhao
使用jinja，很django模板非常相似的另一个模板引擎。
On 12月21日, 下午12时23分, limodou <limo...@gmail.com> wrote:
> 2008/12/21 v cc <vcc....@gmail.com>:
>
> > 2008/12/21 Robert Chen <search.pytho...@gmail.com>
潘俊勇
调django非常好，他只是在打预防针，让django更好的成长。
现在没有一个web框架是完美的，我在弄zope，也知道zope不完美。bfg也只是在早期
limodou说的好，没有完美的终结者，只有不断的变化和发展
On 12月21日, 下午3时58分, Zoom.Quiet <zoom.qu...@gmail.com> wrote:
> 老潘终于回来砸了个大坑哪，，，将 Limodou/R.Chen 这种老仙都惊出来了哪，，，
> Dj 不论如何，现在是快速Web应用框架之首，连GAE 都得默认支持，这得认；
> 模板效率和维护出问题的，只有大型项目和典型的中国项目中，，，
> 其实这都是 HTML 整出来的问题，早用 XML 就没有这么多问题了，
>
> 如果整个页面都是靠 exJS 之类JS生成，就象Gmail 那种页面内容完全JS渲染而成的，
> 模板就可以非常简单了，只要将所有需要的内容整成 JSON 或是XML 丢出来就好，，，
> 但是，这样对UI的要求可就有些变态了，，，
>
> 以上，片段想法，，，
>
> 2008/12/21 闲云无心 <67435...@163.com>:
est
> 演化成更为通用的Web框架。。
>
这个是什么根据？
gasolin
這個 screencast 是 DjangoCon 08 上錄的，有快半年了吧。
YoungKing
Robert Chen
if 是一个最明显的例子，elif 目前应该还是不支持吧。我曾经试图解决这一问题一个东西的设计不是以敲出代码多少来计算的，perl的代码不是很少吗？你已经学会了python，还需要再去学不同的tag语法，这本身就是很奇怪的事。就直接拿django模板本身来说，不支持的功能可以举出很多，而且这些还只涉及到如何表示逻辑，而不是为了要实现所谓的分离，比如
http://code.djangoproject.com/ticket/3090,
这个问题还是由于django模板在解析时不处理结束tag的内容引起的，这其实就是一个设计的问题。再比如，如何简单地在模板中赋值，如何对它进行加工。在for中无法支持range之类的函数。这些不足并不直接与显示与逻辑分离相关，反而是本身功能是否完备的问题。所以也造成一个简单的功能都会出来许多的tag来处理，这是好事情吗？我不这么认为。template不支持python语法是一方面，但是你的功能也尽可能完整吧。
就目前来看我不认为招python程序员会造成成本下降。python还不足以同java, c++相竟争。反而会造成成本上升。个人观点。
显示逻辑应该在哪里处理，这本身就是一个问题。比如我要显示一个table，那么我有许多的数据。现在有几种做法：
1. 在view中生成table的html代码，然后在模板中直接使用。这种方式可以考虑，它的好处是我可以通过python直接生成html代码，减少了template的复杂性。但是如果你的table某一天改为了其它的显示方式，你要改的不是模板，而是代码。为了显示而修改代码，不知道这是大家所期望的吗？
2. 所以我认为也许合理的是view中只传出数据，然后在template中进行显示。那么在template中必然有循环，对数据进行加工这种简单的处理，这必然增加了模板了复杂性，但是实现了数据与显示的分离，我宁肯接受这种方式。
3. view还是传数据，但是数据是在tag中完成的，这样你需要开发一个新的tag，然后在模块中load它。那么与这种方式可以相比较的可以是这样：
{% import my %}
{% my.process(data) %}
既不用写tag语法，也能很方便地通用，也没有增加更多的内容，因为怎么处理都封装在函数中了。
所以从上面的分析，django的方式限制太多，引入了太多djangoic的东西，比如tag的复用。采用函数方式可以很方便的复杂，而tag只能在django中用。想复用可以，把代码拷贝出来改一改吧。
过分的封装反而会造成通用性差，复杂的问题，还不如简化一下。
至于php被诟病具体原因不好说，但我认为并不一定是展示与处理混合造成的，php只一样可以使用模板，更多的应该是管理上。但是无论如何，仍然有许许多多的php的东西做得还是不错。关键是使用的人，语言本身只是其中一方面。
Robert Chen
Cliff Peng
另，给一个真实的案例，最近接了一个项目，用Django做一个类SNS的网站，由于我们美工不行，所以前台是另一家公司负责，他们不太懂Python，我们两家之间正是通过Django的模板完成沟通，我们先做没有任何布局的页面，在模板中给出变量和简单的显示逻辑，他们再对页面进行渲染，进展很顺利，基本不需要问，这个是啥意思，这个是啥功能的问题
也许 Django 模板解决的最大问题是就 Programmer 和 Web Designer 之间的"免"对话问题
我想 Django 团队之所以对自己的作品着迷，一定是在应用中尝到了甜头
但随着用户群的加大，需求的多样性也急剧增加----Django 开发团队能否在眼花缭乱的需求变化中保持清醒头脑
确实令人捏把汗啊
Zoom.Quiet
> 2008/12/22 Robert Chen <search....@gmail.com>
>>
>>
>> 另，给一个真实的案例，最近接了一个项目，用Django做一个类SNS的网站，由于我们美工不行，所以前台是另一家公司负责，他们不太懂Python，我们两家之间正是通过Django的模板完成沟通，我们先做没有任何布局的页面，在模板中给出变量和简单的显示逻辑，他们再对页面进行渲染，进展很顺利，基本不需要问，这个是啥意思，这个是啥功能的问题
>
Limodou 是关注代码完备性的个人玩家，
只有 exoweb ／ 华美汉盛 / 好看薄 以及 R.Chen 的公司等等，才是真正用Dj 面对客户的，
所以，这些体验一直没有出现在会课中，和列表中，
所以，大家不明白哪，，，
Pythonic 的确是够用就好，
但是，作为行者，多想一步，如果不够用了怎么办？！
也是个善举哪，，，比如俺公司里上百万的Dj 相关项目，就是因为多库操作，刚好不是Dj 擅长的，
整的特别烦，，，
这些，是Dj 社区中不会说的，，，
毕竟应用范畴不同，
所以，多吼一些自个儿的实作体验成故事或是小手册吧，
给那些想用Dj 创业的行者们信心和实用资料，，，
> 也许 Django 模板解决的最大问题是就 Programmer 和 Web Designer 之间的"免"对话问题
> 我想 Django 团队之所以对自己的作品着迷，一定是在应用中尝到了甜头
> 但随着用户群的加大，需求的多样性也急剧增加----Django 开发团队能否在眼花缭乱的需求变化中保持清醒头脑
> 确实令人捏把汗啊
>
>>
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
limodou
>>
>> 一个东西的设计不是以敲出代码多少来计算的，perl的代码不是很少吗？你已经学会了python，还需要再去学不同的tag语法，这本身就是很奇怪的事。就直接拿django模板本身来说，不支持的功能可以举出很多，而且这些还只涉及到如何表示逻辑，而不是为了要实现所谓的分离，比如
>> if 是一个最明显的例子，elif 目前应该还是不支持吧。我曾经试图解决这一问题
>> http://code.djangoproject.com/ticket/3090,
>>
>> 这个问题还是由于django模板在解析时不处理结束tag的内容引起的，这其实就是一个设计的问题。再比如，如何简单地在模板中赋值，如何对它进行加工。在for中无法支持range之类的函数。这些不足并不直接与显示与逻辑分离相关，反而是本身功能是否完备的问题。所以也造成一个简单的功能都会出来许多的tag来处理，这是好事情吗？我不这么认为。template不支持python语法是一方面，但是你的功能也尽可能完整吧。
>
>
> 所以我说这归根结底实际是一种审美取向的问题，木头兄眼中Django的模板自然有千般不是，毫无疑问，你提的这些都是事实，我举双手赞同，但我依然认为，Django中不提供这些功能，对我和我的团队来说，再适合不过，很简单，因为我们不需要这些功能。功能是否完整，我不怎么在乎，功能够不够用，才是我关心的。从我们目前的开发经验来说，Django的模板非常合适，不管开发能力如何，开发经验多少，写出来的模板几乎一致，可维护性相当好。如果Django如PHP一般允许嵌入Python代码，我估计管理成本会上升很多。换句话说，我们不需要最敏捷，我们只需要足够敏捷；我们不需要最方便，我们只需要足够方便。
也许只能归于审美的取象或不同的设计哲学了。在我看来模板只是减少重复，提高重用的一种方式。对于一个框架本身，它的约束越少越可以让不同习惯的人使用。不同的人有不同的使用方式，一个团队完全可以在原始框架之上再进行限定。这种限定可以来源于对框架的衍生，也可以由开发团队来自行约定。但这种做法就要求框架本身的限定或少越好，通过提供扩展机制可以无限扩展。而django则不仅约定了框架，还约定了许多的使用要求。但实际上，我认为许多的要求或限定仍然只代表了某些设计思想，它把可以定制化的东西直接等同于框架的能力，所以才会引发象我这样人的不满。就正如Chen所说，django的模板非常适合你们的团队，这一点我不否认，但是未必适合其它的人，至少从我这个没有团队的人的观点来看我认为不够用。
所以我以前也想过一个框架能做什么，应该怎么做？我理想中的框架应该是具有很强的扩展性，功能也足够强大。然后基于这个框架有许多定制化的东西，这些东西约定了更多内容，而且是有偏重的。因此用户可以从最基础的层次做起，或者选择满足自已要求的定制的层次开始。
当然如果只是使用可能很少想这些问题或者不太关心。不过为什么要自已做框架，就是因为我找不到非常让我满意的框架，所以才会尝试着自已去做。
>>
>> 就目前来看我不认为招python程序员会造成成本下降。python还不足以同java, c++相竟争。反而会造成成本上升。个人观点。
>
> 你在招聘的时候当然看不出Python的成本会有优势，如果你招了一个普通程序员，在培训时，就会发现Python的成本优势，这是我们团队的真实体验，至于其他团队，我就不好妄加猜测了。
>
>>
>> 显示逻辑应该在哪里处理，这本身就是一个问题。比如我要显示一个table，那么我有许多的数据。现在有几种做法：
>>
>> 1.
>> 在view中生成table的html代码，然后在模板中直接使用。这种方式可以考虑，它的好处是我可以通过python直接生成html代码，减少了template的复杂性。但是如果你的table某一天改为了其它的显示方式，你要改的不是模板，而是代码。为了显示而修改代码，不知道这是大家所期望的吗？
>> 2.
>> 所以我认为也许合理的是view中只传出数据，然后在template中进行显示。那么在template中必然有循环，对数据进行加工这种简单的处理，这必然增加了模板了复杂性，但是实现了数据与显示的分离，我宁肯接受这种方式。
>> 3. view还是传数据，但是数据是在tag中完成的，这样你需要开发一个新的tag，然后在模块中load它。那么与这种方式可以相比较的可以是这样：
>>
>> {% import my %}
>> {% my.process(data) %}
>>
>> 既不用写tag语法，也能很方便地通用，也没有增加更多的内容，因为怎么处理都封装在函数中了。
>>
>>
>> 所以从上面的分析，django的方式限制太多，引入了太多djangoic的东西，比如tag的复用。采用函数方式可以很方便的复杂，而tag只能在django中用。想复用可以，把代码拷贝出来改一改吧。
>>
>> 过分的封装反而会造成通用性差，复杂的问题，还不如简化一下。
>>
>>
>> 至于php被诟病具体原因不好说，但我认为并不一定是展示与处理混合造成的，php只一样可以使用模板，更多的应该是管理上。但是无论如何，仍然有许许多多的php的东西做得还是不错。关键是使用的人，语言本身只是其中一方面。
>
> table的问题很简单，我们直接用filter就处理了，写一个filter跟写一个函数没什么区别，既不用写tag语法，也能很方便地通用，也没有增加更多的内容，因为怎么处理都封装在filter的函数中了。
>
filter只是针对我所说一种解决方式，但是filter基本上只接受一个参数，第二个参数要通过':xxx'之类的用法，那第2个，第3个呢？处理简单的行，复杂的还是有问题。不管是tag还是filter，远没有调用一个python函数来得方便。既没有新的语法，也可以方便重用。
limodou
> 另，给一个真实的案例，最近接了一个项目，用Django做一个类SNS的网站，由于我们美工不行，所以前台是另一家公司负责，他们不太懂Python，我们两家之间正是通过Django的模板完成沟通，我们先做没有任何布局的页面，在模板中给出变量和简单的显示逻辑，他们再对页面进行渲染，进展很顺利，基本不需要问，这个是啥意思，这个是啥功能的问题
>
这说明不了什么？这只是你们在交互时为了减少问题采用的一种方式，并不表达模板就只能这样，只是说明，这样使用会方便不同人之间的交流罢了。可以通过管理或内部限定来要求。
Robert Chen
Robert Chen
哗这就是实战哪，
......
所以，多吼一些自个儿的实作体验成故事或是小手册吧，
给那些想用Dj 创业的行者们信心和实用资料，，，
--
Robert
关注Python 关注搜索
Dynamic Life——http://blog.csdn.net/balabalamerobert
Steve Nian
>
>
> 2008/12/22 Zoom. Quiet <zoom....@gmail.com>
>>
>> 哗这就是实战哪，
>> ......
>> 所以，多吼一些自个儿的实作体验成故事或是小手册吧，
>> 给那些想用Dj 创业的行者们信心和实用资料，，，
>
> 呵呵，现在经济形式严峻哪，俺们每天都在生死线上挣扎，哪还有这份闲情雅致呀，这两天多看了几眼GMail，都觉得于心不安，罪过啊罪过 ：）
別罪過啊, 這個討論串非常精彩, 很希望有更多這類不同觀點且理性的討論.
limodou
> 所以我们看待Django模板的角度就是不同的，木头兄你是从Web框架的作者去看，而我是从Django的使用者角度去看，所以你看到的是Django模板的千般不是，而我看到的则是它的强制带来的管理成本的降低。我说的案例只是想说明，简单、一致的模板能给我们这个团队带来的好处，Django通过技术手段层面强制，就达到了我们的需求。同时，我们至今没遇到filter要传两个参数才能完成的模板渲染功能，所以这个问题对于我们来说是不存在的，当然，对Web框架的作者来说，这可能是很值得考虑的地方。
> 诚然，你可以提供一个极端灵活的模板，通过管理或内部限定来要求，我的问题是，一旦引入了管理成本和内部限定，第一，它跟Django所提供的模板还有多大的区别呢？第二，如果区别不大，我直接用Django的模板就可以了，为什么还要给团队引入额外的管理成本呢？管理是需要成本的，如无必要，勿增复杂。
在我看来这是能力与限制的差异。首先我认为应该先具备能力，这是框架要做的。然后是在此之上的限制，即如何去使用，这是团队为管理统一制定的使用规范。希望一个框架拿来就用很难，因此一个团队应该在是选择一个框架之后，先进行框架的定制，使它更符合团队的管理要求，使用习惯，经验的积累，这个工作应该由专门的平台搭建人员来完成，然后普通成员在这个定制后的平台上进行工作。这样既解决了框架不用做得大而全，也解决了团队的实际需要。所以在我看来django的模板实际上是能力不完整，限制比较多。所以django的模板我认为不符合我对于框架所要求的能力一说。也就是可以认为它其实是不区分框架本身的能力与定制性的要求，所以造成它不能满足不同层次的人员的要求，对于你可能合适，但对于我可能不合适。
因为模板不管怎么样还算是一个简单的东西，所以也很少有模板系统提供对内部工作进行配置的功能，但是一旦存在，就可以由用户来限定，比如是否可以解析python代码或其它什么的，这样就不仅仅是通过管理上的约定，在执行时也会进行检查。而django的模板并没有考虑到这一点。再说我的很多要求也并不过分啊，比如：if
的表达式可以强一些， 多提供一些python语法的支持，比如for i in
range(10)这样的代码，直接使用python代码，等等。这些其实并不涉及到模板的功能和定位，以及如何使用，反而是模板应该具备什么样的功能的角度来提的。
如果说"我"这个团队认为django的模板因为功能上不完整不满足我的需要，我要么替换它，要么改进它。但是这都增加了"我"的管理成本。对你来说正好适用，成本没有增加，但是对"我"来说不适用，成本增加。
> 咱们看问题的角度不同，所以得出的结论不同，存在的就有其合理性，Django团队的坚持难道就只是偏执狂的一厢情愿？所以我的意思是在木头兄你作为Web框架作者的维度之外，再给大家另一个角度看待Django的模板，当然，我甚至希望能够有更多的角度出现。碰撞才能有火花，如果社区只有一种声音，那就太无味了。
其实你的角度更多还是从管理上，因为django的功能缺失正好符合你们团队的管理要求，所以你认为它好。并不是站在一个模板所应该具备的功能角度上。并且许多功能也并不是要引入更多的python代码，目的只是写程序时可以更方便一点罢了。这些地方方便了，在许多地方可以减少许多的tag,
filter。我不认为只有一种声音，我谈到的都是很具体的，希望django应该做的一些改进，其目的还是希望django更好，更强大，更方便。
你是一个用户，我也是一个用户。但我这个用户不会简单地接受别人的习惯，我有我的习惯，所以当不同的习惯出现冲突的时候，我希望听到的不是简单地说：你的习惯不好，你应该按我的习惯来做。而是希望听到：我的习惯与你不同，但是我可以支持你的习惯，只要你如何如何做。我不知道你喜欢哪种方式。当然我不否认，也许我可以接受你的习惯。但是前提是它是可以被接受的，在我经过深思熟虑之后。
Zoom.Quiet
> 2008/12/22 Robert Chen <search....@gmail.com>:
>> 所以我们看待Django模板的角度就是不同的，木头兄你是从Web框架的作者去看，而我是从Django的使用者角度去看，所以你看到的是Django模板的千般不是，而我看到的则是它的强制带来的管理成本的降低。我说的案例只是想说明，简单、一致的模板能给我们这个团队带来的好处，Django通过技术手段层面强制，就达到了我们的需求。同时，我们至今没遇到filter要传两个参数才能完成的模板渲染功能，所以这个问题对于我们来说是不存在的，当然，对Web框架的作者来说，这可能是很值得考虑的地方。
>> 诚然，你可以提供一个极端灵活的模板，通过管理或内部限定来要求，我的问题是，一旦引入了管理成本和内部限定，第一，它跟Django所提供的模板还有多大的区别呢？第二，如果区别不大，我直接用Django的模板就可以了，为什么还要给团队引入额外的管理成本呢？管理是需要成本的，如无必要，勿增复杂。
>
> 在我看来这是能力与限制的差异。首先我认为应该先具备能力，这是框架要做的。然后是在此之上的限制，即如何去使用，这是团队为管理统一制定的使用规范。希望一个框架拿来就用很难，因此一个团队应该在是选择一个框架之后，先进行框架的定制，使它更符合团队的管理要求，使用习惯，经验的积累，这个工作应该由专门的平台搭建人员来完成，然后普通成员在这个定制后的平台上进行工作。这样既解决了框架不用做得大而全，也解决了团队的实际需要。所以在我看来django的模板实际上是能力不完整，限制比较多。所以django的模板我认为不符合我对于框架所要求的能力一说。也就是可以认为它其实是不区分框架本身的能力与定制性的要求，所以造成它不能满足不同层次的人员的要求，对于你可能合适，但对于我可能不合适。
>
> 因为模板不管怎么样还算是一个简单的东西，所以也很少有模板系统提供对内部工作进行配置的功能，但是一旦存在，就可以由用户来限定，比如是否可以解析python代码或其它什么的，这样就不仅仅是通过管理上的约定，在执行时也会进行检查。而django的模板并没有考虑到这一点。再说我的很多要求也并不过分啊，比如：if
> 的表达式可以强一些， 多提供一些python语法的支持，比如for i in
> range(10)这样的代码，直接使用python代码，等等。这些其实并不涉及到模板的功能和定位，以及如何使用，反而是模板应该具备什么样的功能的角度来提的。
>
> 如果说"我"这个团队认为django的模板因为功能上不完整不满足我的需要，我要么替换它，要么改进它。但是这都增加了"我"的管理成本。对你来说正好适用，成本没有增加，但是对"我"来说不适用，成本增加。
>
>> 咱们看问题的角度不同，所以得出的结论不同，存在的就有其合理性，Django团队的坚持难道就只是偏执狂的一厢情愿？所以我的意思是在木头兄你作为Web框架作者的维度之外，再给大家另一个角度看待Django的模板，当然，我甚至希望能够有更多的角度出现。碰撞才能有火花，如果社区只有一种声音，那就太无味了。
>
> 其实你的角度更多还是从管理上，因为django的功能缺失正好符合你们团队的管理要求，所以你认为它好。并不是站在一个模板所应该具备的功能角度上。并且许多功能也并不是要引入更多的python代码，目的只是写程序时可以更方便一点罢了。这些地方方便了，在许多地方可以减少许多的tag,
> filter。我不认为只有一种声音，我谈到的都是很具体的，希望django应该做的一些改进，其目的还是希望django更好，更强大，更方便。
>
> 你是一个用户，我也是一个用户。但我这个用户不会简单地接受别人的习惯，我有我的习惯，所以当不同的习惯出现冲突的时候，我希望听到的不是简单地说：你的习惯不好，你应该按我的习惯来做。而是希望听到：我的习惯与你不同，但是我可以支持你的习惯，只要你如何如何做。我不知道你喜欢哪种方式。当然我不否认，也许我可以接受你的习惯。但是前提是它是可以被接受的，在我经过深思熟虑之后。
>
喵的，可以随意创造出新轮子的，那就不是用户了，而是作者了！
俺只想吼的就是，
R.Chen ! 每日一百字，将Dj 刚好够用的体验系列化分享出来吧！
Limodou ！每日5百字，将你对Dj 的怨念和UliWeb 的对策系列化增补到 UliWeb 的文档中吧！
这样，大家才可以全面的理解不同侧面的谅解，决策时才靠谱哪，，，
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
向靠谱,反脑残!
vicalloy
既然使用就需要接受这种风格，如果觉得接受不了就选别的吧（好像django不太适合木头兄:-)了）。
如果一种框架通用性可以做大适合几乎所有人的时候，那这个框架也好用不到哪去。
我最开始对在模板里写python代码也有很强的意愿，写过几个tag和filter后其实也还好。
大多数情况下写个tag并不比在模板里写代码麻烦多少（有时候还是有些不顺）。
那个演讲的文字版本我简单的看了下。
大意就是说django的整合度太高，既不用别人的，也不能给别人用。
但在我看来这没什么不好。
可以吸取别的组件的优点，但没必要一定要以某组件做基础。
一开始就是以一个整体设计的，这样才能提供足够的整合度。
我就是厌倦了Java那一打的开源项目才用django的。
PS:
我觉得Django是最不像ROR的类ROR框架，却又是最像ROR的框架。
2008/12/22 limodou <lim...@gmail.com>:
limodou
造轮子的很重要的一个原因就是因为原来的轮子满足要求。如果满足了，当然不必造了。因此当框架足够灵活，又提供方便的配置手段，自然会减少许多的轮子。这样我们看到的就是：框架还有基于框架的各种模式。每个用户都可以有自已的模式，一种模式就是一种使用习惯。当用户找不到适合自已习惯的模式时，他可以自行创建。但是框架还是框架，不会因为模式的变化而发生太大的变化。但是为了支持多种模式，需要框架足够灵活。
>
> 俺只想吼的就是，
> R.Chen ! 每日一百字，将Dj 刚好够用的体验系列化分享出来吧！
> Limodou ！每日5百字，将你对Dj 的怨念和UliWeb 的对策系列化增补到 UliWeb 的文档中吧！
我做uliweb可不是为了反对django，只不过是把自个儿理解的框架实现出来罢了，许多地方并不一定做得比django好。就是写的话也只会写uliweb会如何做，而不是别人是如何做不到的。
> 这样，大家才可以全面的理解不同侧面的谅解，决策时才靠谱哪，，，
Elias Soong
vicalloy 写道:
> 我觉得每种框架都有自己的风格。
> 既然使用就需要接受这种风格，如果觉得接受不了就选别的吧（好像django不太适合木头兄:-)了）。
> 如果一种框架通用性可以做大适合几乎所有人的时候，那这个框架也好用不到哪去。
> 我最开始对在模板里写python代码也有很强的意愿，写过几个tag和filter后其实也还好。
> 大多数情况下写个tag并不比在模板里写代码麻烦多少（有时候还是有些不顺）。
>
> 那个演讲的文字版本我简单的看了下。
> 大意就是说django的整合度太高，既不用别人的，也不能给别人用。
> 但在我看来这没什么不好。
> 可以吸取别的组件的优点，但没必要一定要以某组件做基础。
> 一开始就是以一个整体设计的，这样才能提供足够的整合度。
> 我就是厌倦了Java那一打的开源项目才用django的。
>
> PS:
> 我觉得Django是最不像ROR的类ROR框架，却又是最像ROR的框架。
>
妙。这个演讲则很多时候是探讨发展，很担心以后会演变为Zope社区、Django社
区、其他Python Web技术社区，相互之间谁都很难利用他人的贡献，重用率很低、
各玩各的这种比较糟糕的状况。作者最后给出一种参考解决方案是wsgi。
如果Web编程像一般Python编程那样，对遇到的问题常能有一个比较明显的解决方
案，那日子会舒服得多吧。
limodou
> 我觉得每种框架都有自己的风格。
> 既然使用就需要接受这种风格，如果觉得接受不了就选别的吧（好像django不太适合木头兄:-)了）。
这里风格其实不是一种，而是多种，可以理解为特性。比如urls.py，模板，app等。其实我对于django的app组织还是很喜欢，只不过我认为它做得不够充分，正如我认为django的模板不够充分。orm我也认为django的还挺好。只不过我认为现有的不好的风格，在别人看来不原意去改进或认为我的风格不好，所以只好自已搞了。在uliweb中，我仍然是借用了django的app的管理方式，orm也和django的很象。再如web2py，这是我在django之后又研究了一段时间的框架，也做了一些贡献。它有好有坏。模板，我个人认为简单，灵活，强大。所以我用在了uliweb中。view中对request,
response的简化（在view方法中不需要定义request,
response可以直接使用，可以减少一些代码，更方便）。不过它的app之间在当时是完全独立的，一个app就可以理解为一个应用。与django中的app只不过是一个应用中的最少组织单位不同，所以我认为这种方式也不好。于是也向作者提出建议，但是很难被采纳。再加上对于向后兼容的看法，原作者认为很重要，我认为在增加功能时不用过分考虑这个问题，在这方面也存在差异，所以现在也很少关注了。
所以一个框架不被接受并不表示你完全否定了它，可能只是因为某些内容无法满足要求造成的。所以我的确选择别的了。
> 如果一种框架通用性可以做大适合几乎所有人的时候，那这个框架也好用不到哪去。
一直就不认为一个框架可以适合所有人。而且我认为框架本身也在进化过程中，框架也需要积累。因此如果把框架分出层次来：基础层和应用层。基础层可以被框架定制人员来进行配置从而形式某种模式的应用层，它主要是面对框架定制人员。应用层，是真正面向用户的层，它可能有许多，每一种可能满足某种开发习惯或开发方式。只是想法，还没有想太好。其实做web就那么些事，很多，很杂。框架就是把这些东西有机的结合起来，提供方法供用户去操作。如何去组织，去管理，去操作，如何让用户方便，如何提高复用，如何积累，这些是框架最重要关心的问题。
> 我最开始对在模板里写python代码也有很强的意愿，写过几个tag和filter后其实也还好。
> 大多数情况下写个tag并不比在模板里写代码麻烦多少（有时候还是有些不顺）。
filter还好，基本上就是一个函数。而tag则要复杂得多。我做过复杂一些的tag，为了实现不得不通读template的代码，难度还是有的。特别是在处理tag的参数时，如果你允许参数可以是变量名的时候。
>
> 那个演讲的文字版本我简单的看了下。
> 大意就是说django的整合度太高，既不用别人的，也不能给别人用。
> 但在我看来这没什么不好。
> 可以吸取别的组件的优点，但没必要一定要以某组件做基础。
> 一开始就是以一个整体设计的，这样才能提供足够的整合度。
> 我就是厌倦了Java那一打的开源项目才用django的。
>
其实在那段视频中讲到django和共它的tg,
pylons之间存在着界线，它们之间基本上不能通用，而tg和pylons之间许多东西可以通用。这种是不是有必要先不用去说，只是说明：我们要的是竞争，还是互相促进。django中的许多东西想拿出来用很不方便，一方面它内部关联太多，可以从视频上看到，不够独立，另一方面可能就是配置了。
举例来说：从一开始我就不喜欢那个DJANGO_SETTINGS_MODULE，真是麻烦死了，它甚至都不能有个缺省的判断。
http://code.djangoproject.com/ticket/824
在这个ticket我其实是想说当不存在时可以有一个缺省的判断。但是下面的回复却是告诉我在使用前应该设置一下。
http://code.djangoproject.com/ticket/904
在这个ticket下，有人给出一个缺省查找的补丁，但是被拒绝，应该是通过 django.conf.settings.configure()
来手工设定，还是很麻烦。
这只是一个例子。说明django在某些地方的独立性和智能化(或缺省设置)的处理上还不够。
> PS:
> 我觉得Django是最不像ROR的类ROR框架，却又是最像ROR的框架。
>
> 2008/12/22 limodou <lim...@gmail.com>:
>> 你是一个用户，我也是一个用户。但我这个用户不会简单地接受别人的习惯，我有我的习惯，所以当不同的习惯出现冲突的时候，我希望听到的不是简单地说：你的习惯不好，你应该按我的习惯来做。而是希望听到：我的习惯与你不同，但是我可以支持你的习惯，只要你如何如何做。我不知道你喜欢哪种方式。当然我不否认，也许我可以接受你的习惯。但是前提是它是可以被接受的，在我经过深思熟虑之后。
>
--
张沈鹏
leopay
我觉得每种框架都有自己的风格。
既然使用就需要接受这种风格，如果觉得接受不了就选别的吧（好像django不太适合木头兄:-)了）。
如果一种框架通用性可以做大适合几乎所有人的时候，那这个框架也好用不到哪去。
我最开始对在模板里写python代码也有很强的意愿，写过几个tag和filter后其实也还好。
大多数情况下写个tag并不比在模板里写代码麻烦多少（有时候还是有些不顺）。
那个演讲的文字版本我简单的看了下。
演讲的文字版可否共享下？
vicalloy
> 演讲的文字版可否共享下？
limodou
> 2008/12/22 leopay <leo...@gmail.com>:
>> 演讲的文字版可否共享下？
>
> http://arstechnica.com/journals/linux.ars/2008/09/09/ars-at-djangocon-what-django-can-learn-from-zope
>
好象不是原话的记录。内容不全。
vicalloy
> 2008/12/22 vicalloy <zbi...@gmail.com>:
>> 2008/12/22 leopay <leo...@gmail.com>:
>>> 演讲的文字版可否共享下？
>>
>> http://arstechnica.com/journals/linux.ars/2008/09/09/ars-at-djangocon-what-django-can-learn-from-zope
>>
>
> 好象不是原话的记录。内容不全。
恩不是原话，类似个总结之类的。
视频我看了一点点，感觉这兄弟废话确实很多:-)。
前面怕得罪人，花了很长时间解释自己不是来砸场子的。
不过对于admin的评价我还是有些赞同的。
admin给的太多，也让你无从下手。
相对来说像ROR那样自动生成一个简陋的编辑页面，可能会是一个更好的startup。
jjx
cookie,或者是request.get/post/meta之类的，但是model其实是不存在着这些东西，而且django模板不支持方法调
用，所以我现在用的方法是在视图中向model注入变量，比方说论坛主题的图标，像锁定，热贴都可以依赖thread对象本身的属性，而是否新帖，则要
看当前用户的最后登录时间（复杂时还要考虑他本次看了多少贴子)
伪码
view ..
def thread(request,id):
thread=Thread.objects.get(id=id)
setattr(thread,'browser',request.user)
model...
class Thread(models.Model):
def get_icon(self):
if self.lock:
return 'lock.gif'
elif self.posts>10:
return 'hot.gif'
elif hasattr(self,'browser'):
user=self.browser
if self.time>user.forum_user.last_visit:
return 'new.gif'
..............
在模板中就是调用thread.get_icon
大家可以讨论一下有什么更好的方法
@@
vicalloy
@@
韩天峰
flya flya
@@
http://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request
Joe
韩天峰
Cliff Peng
如果你是非专业人士，足够用了。比如非IT公司的IT部门。专业IT公司的，就别考虑了！DJango很好用，但是并没有为专业的程序员带来多少好处，遇到难度比较大，复杂的问题时，反倒不如不用它的好！
要说专业，我看 Zope 够专业，前些年也比较火，可惜国内玩的人太少了
Zoom.Quiet
看一看这个线索的发起人就知道你的回答雷在哪儿了，，，
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
Cliff Peng
2008/12/22 Cliff Peng <szha...@gmail.com>:
> 2008/12/22 韩天峰 <mikan...@gmail.com>兄台的回复很雷哪，，，
>>
>> 如果你是非专业人士，足够用了。比如非IT公司的IT部门。专业IT公司的，就别考虑了！
>> DJango很好用，但是并没有为专业的程序员带来多少好处，遇到难度比较大，复杂的问题时，反倒不如不用它的好！
>
> 要说专业，我看 Zope 够专业，前些年也比较火，可惜国内玩的人太少了
看一看这个线索的发起人就知道你的回答雷在哪儿了，，，
哈哈，本来很多问题的讨论就是在绕圈子，我是想率先带大家回到起点
PS:现在国内 Django 确实比 Zope 要火得多，尽管不够专业，像个玩具……等等，等等
woods
On 12月22日, 下午7时19分, "韩天峰" <mikan.te...@gmail.com> wrote:
> 我觉得，Django很有特点，比如url，model、views、templates、admin。但是好几个地方，基本上如同玩具，。比如模板系统，实在太差，根本无法与PHP的smarty相抗衡。PHP的smarty，在不结合php代码的情况下，就几乎能满足所有要求。而且smarty允许适当情况下加入php的代码。实际上php的smarty已经可以称之为是产品级的模板技术了。
> 而Django的模板，除了能执行一些简单的循环、遍历、if判断，之外就没有其他的能力了。要想实现一些复杂的模板操作，只能借助于tags，filter，或者是js脚本。
>
> 还有urls，views，models，其实都很玩具，刚开始觉得还不错，但是做实际项目的时候，就像鸡肋一样。
>
> 2008/12/22 @@ <ask...@gmail.com>
>
>
>
> > context processor最合适了 user这个本来就是有自带的processor的
>
> > 2008/12/22 vicalloy <zbir...@gmail.com>
>
> >> 加个TEMPLATE_CONTEXT_PROCESSORS或Middleware就行。
>
> >> 要不写成Tag。
>
> >> 2008/12/22 jjx <jiangjianx...@gmail.com>:
韩天峰
@@
韩天峰
@@
<table>
{% for item in alist %}
<tr class="{% cycle 'white' 'gray' %}">
<td>{{item.a}}</td><td>{{item.b}}</td><td>{{item.c}}</td>
</tr>
{% endfor %}
</table>
vicalloy
2008/12/23 韩天峰 <mikan...@gmail.com>:
jjx
计算啊，最终你还是要做tag，做filter,而个人以为，写tag,filter都是在将模板实现复杂化，背离其本意，这样的话，不如一开始就用
mako之类的来的干净
所以这些判断和计算最好的落脚点就在model的实例方法，但model中并没有request的概念，所以需要有一种将request中的东西传给
model而不失去优雅的方法
韩天峰
@@
这样的话我先我不会用table。 因为他就是一个list 那用ol或者ul都更贴近需要表达的意思。直接float left就可以了。 然后cycle 'white' 'white' 'white' 'gray' 'gray' 'gray' (这个cycle不知道有没有更合适的写法？）
用table的话不知道可以不可以这样，手里没django测试一下
<table>
{% cycle 'white' 'white' 'white' 'gray' 'gray' 'gray' as rowcolors %}
{% for item in alist %}
{% if forloop.first %}
{% ifchanged %}<tr class={{rowcolors }}>{% endifchanged %}
{% else %}
{% ifchanged %}</tr><tr class={{rowcolors }}>{% endifchanged %}
{% endif %}
<td>item</td>
{% if forloop.last%}
</tr>
{% endif %}
{% endfor %}
</tabble>
韩天峰
刘鑫
页面设计师，给出的是表格的排版。作为程序员，是不会去动他的html的。还有，如果是4列，5列呢？呵呵， @@ ask...@gmail.com，对django的模板了解够多，佩服！不过Django也很好用呀，我自己在gae上的博客就是用它写。Django很方便，很好用。当然有时候又觉得不够用。
--
杀人放火金腰带，补路修桥无尸骸。
……
劉鑫
March.Liu
vicalloy
v cc
list的item没有a , b,他只是一个list，元素是单个的字符串。这些字符串3个为一行，没行颜色，不同。这个实际是对 forloop.counter %，取余数操作。 cycle 同样不适用。我的解决办法是，循环td，写一个tag，判断forloop.counter 实现分行。js脚本来实现，隔行颜色。
张沈鹏
> 还是不懂django啊，都盯着tag，没看到filter。这样：
>
> {% if forloop.counter|divisibleby:"3" %} some color {% endif %}
>
.... 太丑了
shhgs....@gmail.com
On 12月20日, 下午11时44分, "Robert Chen" <search.pytho...@gmail.com> wrote:
> 嗯，现在我已经看到两种"开放的"社区的理解了~~
>
> 2008/12/21 zhao shichen <shichen.z...@gmail.com>
>
> > 嗯，这就是开放社区的特点：哲学家的比例要超过coder。
>
> --
> Robert
> 关注Python 关注搜索
> Dynamic Life----http://blog.csdn.net/balabalamerobert
v cc
>.... 太丑了
> 还是不懂django啊，都盯着tag，没看到filter。这样：
>
> {% if forloop.counter|divisibleby:"3" %} some color {% endif %}
>
<table>
{foreach from=$items key=myId item=i name=foo}
{if $smarty.foreach.foo.index % 5 == 0}
<tr><th>Title</th></tr>
{/if}
<tr><td>{$i.label}</td></tr>
{/foreach}
</table>
Django: {% if forloop.counter|divisibleby:"5" %}
limodou
我不知道前端人员都是些什么人？我想知道ajax前端该由谁来做？js是非程序员的活吗？
我认为模版不过是为了展示，为了分工，但是并不是为了区分程序员和非程序员的吧。如果我要在django中加入ajax这块东西非程序员干得了吗？如果干不了，非程序员到底做了些什么？
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: (new)http://http://hi.baidu.com/limodou
(old)http://www.donews.net/limodou
@@
我不知道前端人员都是些什么人？我想知道ajax前端该由谁来做？js是非程序员的活吗？
我认为模版不过是为了展示，为了分工，但是并不是为了区分程序员和非程序员的吧。如果我要在django中加入ajax这块东西非程序员干得了吗？如果干不了，非程序员到底做了些什么？
js和模板应该没关系啊，现在不都是要unobtrusive 该怎么显示还是怎么显示。
不过只是猜想。。现在工作和这些都没关系。。。
Zoom.Quiet
离题十万里了，讨论 Dj 特性和对策，另开线索吧，，，，
这个主题是推广 Zope3 的哪，，，
2008/12/23 @@ <ask...@gmail.com>:
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
阿信
在 08-12-23，Zoom. Quiet<zoom....@gmail.com> 写道：
--
正如我的邮箱名一样，我做人的哲学是：信行谦言。
@@
咳！
离题十万里了，讨论 Dj 特性和对策，另开线索吧，，，，
这个主题是推广 Zope3 的哪，，，
回到主题。。
标题和视频内容有点对不上啊。。
感觉视频说的是说django应该从zope里吸取哪些教训，而不是学些什么:p
limodou
js不是要写在模板中吗？我主要是想问，使用模板的人，与做js，css的算不算一拨人？它们可以都认为是前端的技术，而模版也更多是为前端人员准备的。js本身也是一种语言，css也不能算是简单。这些东西对人的要求都很高。所以前端人员更多时候我认为就应该是程序员，不过偏重于前端开发的程序员。
韩天峰
limodou
> 模板让前台人员去做？？那是不现实的，模板标签代码、ajax、views，都是应该由程序员做的。
> 不可能实现完全隔离的。实际上，前台设计只是给一个静态页面，所有动态的功能，都是由程序员考虑的。
>
> django的模板不支持python代码，导致了程序员不能按照程序员的思维来处理问题。还得绕几个弯。
> 另外，urls需要手工写，不能自动映射，复杂的项目，简直不堪忍受。只好接管了urls，自己来处理了。
自已接管urls?那不是要修改核心代码？
v cc
2008/12/23 韩天峰 <mikan...@gmail.com>:
> 模板让前台人员去做？？那是不现实的，模板标签代码、ajax、views，都是应该由程序员做的。自已接管urls?那不是要修改核心代码？
> 不可能实现完全隔离的。实际上，前台设计只是给一个静态页面，所有动态的功能，都是由程序员考虑的。
>
> django的模板不支持python代码，导致了程序员不能按照程序员的思维来处理问题。还得绕几个弯。
> 另外，urls需要手工写，不能自动映射，复杂的项目，简直不堪忍受。只好接管了urls，自己来处理了。
韩天峰
{{ content|striptags|truncatewords_zh:30|urlize|linebreaksbr }} ？这么多的filter不知道性能怎么样呢？要是我直接在程序里边处理好了。
limodou
> 2008/12/23 limodou <lim...@gmail.com>
>>
>> 2008/12/23 韩天峰 <mikan...@gmail.com>:
>> > 模板让前台人员去做？？那是不现实的，模板标签代码、ajax、views，都是应该由程序员做的。
>> > 不可能实现完全隔离的。实际上，前台设计只是给一个静态页面，所有动态的功能，都是由程序员考虑的。
>> >
>> > django的模板不支持python代码，导致了程序员不能按照程序员的思维来处理问题。还得绕几个弯。
>> > 另外，urls需要手工写，不能自动映射，复杂的项目，简直不堪忍受。只好接管了urls，自己来处理了。
>>
>> 自已接管urls?那不是要修改核心代码？
>
>
> 呵呵，没这么牛B，django.views.static.serve 就是这么干了，django确实可以让你很容易这么干。例如：
> def myserver(request):
> return render_to_response(request.path.lstrip('/'))
等于自已再做或换一套url的处理机制。
>
> 说道前端人员，不可否认，他们可能是程序员，例如javascript，css，html，但是他们很可能不是Python程序员或者PHP程序员。要让他们很方便的按自己的方式去做，不要强迫他们用Python或者PHP。
我认为既然我们都不是前端开发人员，就不要把人家想得那么不堪。javascript也是一种语言，如果这个能弄，本身就是已经会编程了，只不过不是python而已。再说了，他们的方式就一定是好的吗？当然也不能说他们的方式不好。所以这就是我一直想表达的，如何使用应该交由用户来决定，而有没有这种能力应该是框架关心的。但是django很显然给我规定了，它的模板就是适合前端人员，这根本就是越俎代庖的事。凭什么人家前端人员就不想写些复杂点的表达式，创建一个变量，让循环更方便点。这里还没有说更复杂的python代码。还有些前端人员可能前身就是程序员或对编程不感冒，何必让我们替它们操心呢？
>
> 说道ajax，要指出很有趣的一点是：他们用javascript去处理远比我们为他们提供解决方案要好的多，不要忘了，javascript就是专门处理这个事情的，远比Django，Python专业。如果他们需要写大量的javascript代码，毫无疑问他们会按Javascript的方式去做，而不是试图在web框架中寻求一个中间解决方案。
所以更说明前端的复杂远不是搞模板限定一下功能就可以搞定的。django只是把模板分了个工，有些想当然。至于ajax的处理不也都是javascript方式，象ror中的ajax封装，象gwt的java封装，仍然说明还有许多的选择。举ajax只是一个例子，为了说明模板本身就是为了展示，没必要与工作分工放在一起说事。所以我谈到的django的模板功能弱，并不是从分工的角度，还是从框架本身功能上谈的。功能的限制不是用来分工的理由。
>
> 说道好看，看一下django模板这个片段：
> {{ content|striptags|truncatewords_zh:30|urlize|linebreaksbr }}
> 把html的内容截取30字再按自己的格式转换一下
> 和这样做：
> =linebreaksbr(urlize(truncatewords_zh(striptags(content),30)))
> 哪个更清晰一些？毫无疑问，第一个更清晰，因为他的思路是连贯的，不要你倒推，而且我怀疑如果可以在模板里写代码的话，你还会把这些方法包装成函数重用吗？很可能是这样的代码：
> content=striptags(content)
> content=content[:30]
> word_split_re = re.compile(r'(\s+)')
> words = word_split_re.split(content)
> for word in words:
> .........
>
> django做出这样的选择是有他自己的原因的，如果他每个需求都去满足，很快他就会变成500万行代码的比ZOPE还庞大的家伙了。
>
我不认为需要django实现所有的需求，我提得都很实际啊。正是因为简单的东西它不支持，比如复杂的if，结果搞出一堆if开头的tag，简单的事情反而变复杂了，而且这些东西根本没有人管理，虽然有个网站，但是我看django的团队根本不去关注，也从来没有想过哪些是可以放在django项目中的，所以价值有限。结果本来代码可以更少，现在倒是更庞大了，与你说的不正好相反吗？