Python论坛  - 讨论区

标题:[zeuux-python] [CPyUG:58154] 设计的威力 - 什么才是更好的WEB框架

2008年07月04日 星期五 23:51

Zoom.Quiet zoom.quiet在gmail.com
星期五 七月 4 23:51:44 CST 2008

收录在: http://wiki.woodpecker.org.cn/moin/MiscItems/2008-07-04

2008/7/4 v cc <vcc.163在gmail.com>:
> 最近看多了这样的言论:用一个最基本的,再自己用最好的Class来组合扩展,就是一个更好的框架,什么MVC、ORM、Cache、I18N等等,都是很容易加的,.....
> 深不以为然。
>
> 为了避免不必要的误解,首先定义下什么是"更好"的WEB框架。顾名思义,更好就是比现有所有框架都要好。它不是指你在XXX上加了一个功能比XXX好就是更好,也不是你喜欢它就是更好。也许某个框架更适合你,但不能称它是更好的框架。
>
> OK,言归正传。说把一大堆Class,哪怕它们单个都是"最好"的class,拼凑在一起就比一个从一开始就非常完整、精妙设计的框架更好听起来实在有点离谱。任何一个稍微有点软件工程概念的人都知道这是不可能的。
>
> 不服?好,我们用事实说话。MVC、ORM、Cache、I180N很容易加吗?非也。最近把trac应用到公司的开发管理中,大名鼎鼎的trac啊,trac的开发团队还开发着一大堆好的不得了的东东啊,例如genshi模板系统,厉害得不得了。虽然他们还开发了一个专门做I18N的Babel,然而很不幸,trac的i18就有问题,莫名其妙的问题,i18n不完整。最重要的ticket这个页面居然有些字段不能i18n!!!
> 为什么?这就是一个开始没做过完整设计而不断的打补丁来实现新功能的结果。
>
> trac组合了sqlalchemy这个目前看来也许是"最好"的Python
> ORM,然而很不幸,sqlalchemy却不合用,因为它不能为定义的字段定义一个label来你在页面显示的时候用。这也不能怪sqlalchemy,因为它不是为web框架设计的,它不需要加这些多余的东西,加了这些东西它反而不是一个干净的ORM了。看看Django的设计:
> class MyModel(models.Model):
>        name = models.CharField(_('名称'),max_length=20)
>
> 用于页面显示时的字段名,做i18n多容易实现啊!从这里就看出设计的威力出来了吧!
>
> 我是怎样解决trac的i18n问题的?说起来也挺恶心,我在ticket的模板里这样干:
> 先定义一个函数:
>     
>         
>           类型
>    里程碑
>    优先级
>    关键字
>    版本
>    组件
>    抄送
>    描述
>    总结
>    属主
>    状态
>    ${name}
>  
>     
>
> 再在取field.name时这样干:
> ${ZhFieldName(field_name)}
>
> ticket的form是这样的:
>         
> py:if="'TICKET_CHGPROP' in perm(ticket.resource) or > (not ticket.exists and 'TICKET_CREATE' in perm)" > py:with="fields = [f for f in fields if not f.skip]"> > ${ticket.exists and 'Change ' or ''}Properties >
> > > > > value="$ticket.summary" size="70" /> > > > > > > > > name="field_reporter" > value="${ticket.reporter}" size="70" /> > > > > > or not ticket.exists"> > > > > > > > > > 'textarea')" > py:with="fullrow = len(row) == 1"> > > > > py:strip="field.type == 'radio'"> > ${ZhFieldName(field.edit_label or field.label or field.name)}: > > > > colspan="${fullrow and 3 or None}"> > > > name="field_${field.name}"> > > > selected="${ticket[field.name] == option or > None}" > py:content="option"> > > label="${optgroup.label}"> > > selected="${ticket[field.name] == option or > None}" > py:content="option"> > > > > > > name="field_${field.name}" > checked="${ticket[field.name] == '1' and > 'checked' or None}" value="1" /> > > name="field_checkbox_${field.name}" value="1" /> > > > py:for="idx, option in enumerate(field.options)"> > > value="${option}" > checked="${ticket[field.name] == option or > None}" /> > ${option} > > > > > ${field.cc_entry} > > name="cc_update" > title="This checkbox allows you to add or remove > yourself from the CC list." > checked="${field.cc_update}" /> > > > > > title="Space or comma delimited email addresses > and usernames are accepted." > name="field_${field.name}" > value="${ticket[field.name]}" /> > > > > id="field-${field.name}" > name="field_${field.name}" > value="${ticket[field.name]}" /> > > > > > > > > > > 这是不是更好了?我感觉一点都不好。这就是大名鼎鼎的genshi模板系统,有人认为它是最好的模板系统。可是写的template真的好难读啊,就连我这么有经验的开发人员看着都觉得头大。这也不能怪genshi,它只是一个模板语言啊,更高层的Form之类的设计不是它应该干的活啊。如果用django的newforms来实现,那可得多省心啊。 > > 瞧我这补丁打的,这还算简单了,至少在模板里就搞定,不用去碰它的代码。但是如果做过好的i18n的设计,根本就不会碰到这个问题;如果对HTML表现层做过好的设计,也绝对不用写这样难看懂的template。 > > 我最近还干过一件事,花了一个下午改django-pyodbc的backend到django最新开发版。django的数据库层已经做过重构,清晰了许多,让我也没费太大力的就完成了,这就是出色设计所带来的威力! > > 什么是更好的WEB框架,我相信每个人心里都有数了。让我们更靠谱一点,谦虚一点,好好吸收优秀设计的营养,说不定哪一天,我们也可以设计出"更好"的框架来! > ^_^ > > vcc > _ > 没有最好,只有更好! > > -- http://zoomquiet.org''' 过程改进乃是催生可促生靠谱的人的组织! PE keeps evolving organizations which promoting people be good!'''

[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-python]

如下红色区域有误,请重新填写。

    你的回复:

    请 登录 后回复。还没有在Zeuux哲思注册吗?现在 注册 !

    Zeuux © 2024

    京ICP备05028076号