I have a dream

是关于Uliweb,刚刚回复了limodou的新的留言:

发现你好像误解我的意思了,我并不是在和你争论Uliweb和Django那个更优秀,因为这个各人有各人的见解,不依靠武力(?)手段很难得到口径上的统一。我评论Uliweb其实主要还是表达一下自己对某种新框架的向往,因为发现目前Uliweb并不能达到我的要求。

我也不反对造轮子,但是目前吧Uliweb对我来说就不像是轮子,更像是车子。举个例子,某人搞了一家汽车厂,但是造的车的各个部件都是从其他不同 工厂里拿来的,那他造出来的车最初肯定是颇受争议的,而且有一个问题,这个车是缺少自己核心的技术的,其他人采用相同的法子也可以弄出类似的车子来竞争。 但是可以肯定的是,只要不在这最初的一步上驻足自封,而是发展自有的核心技术,那么在争议之后这厂子仍然能继续生存下去,甚至打出自己的品牌。

就Uliweb来说,我不知道现在limodou大牛你现在引入了多少自有的核心组件,但是应该也会有蛮多人和我一样由于看不到这些核心特性而口吐 唾沫星子的。你别太在意就行。既然你觉得Django团队并不那么容易接受,请坚持你现在的这条道路。希望将来Uliweb能够有足够多的理由让更多的 Django用户叛变过来:P

那我自己所希望看到的框架是什么样的呢?说起来其实蛮简单的,甚至谈不上框架,只是一个Pluggable的各种框架的连接器。那这个“连接器”有什么特点呢?

  1. 各组件之间搭配的可定制性。作为一个开发人员,可以自定义开发时使用哪种模板渲染系统、哪种ORM系统等等。比如你可以在全局定义使用jinja2的模板,然后在一个app下定义使用mako的模板。一切都是可以灵活配置的。
  2. 其他框架下的应用的复用性。这将最大化一个app的应用范围,在这套“连接器”的控制下,可以方便的把django的app或者uliweb的app等等集成进来。

看上去是很美好的不是么,挺朴素的功能,但是实现起来也许就不是那么容易的事了。兴许某一天我会发现这么一个满足条件的框架,又兴许某天我自己耐不住了自个儿尝试去实现这么个东西。但是就目前嘛,还是先拿着Django好好学习去吧,还有很多值得我学习的东西呢。

回复limodou关于uliweb给我的评论

来只是随便写写的,没做啥seo,没想到直接把limodou给招来了,今天看analytics发现他的关于《谈谈我对Uliweb的看法》的回复给我带来了n多流量,没见过大世面的我是看花眼了@@

就Django而言,我并不认为是一个大杂烩。首先框架的核心都是Django所自有的,而contrib中的东西事实上对个人应用而言是可有可无的。我也不是说杂烩不好,虽然我现在是用的Django,事实上debug用的还是werkzeug。我的想法是,不要太杂就行,开发时可能不会觉得,可是也许时间长了维护起来就不方便了。

大一统么,我也就是说说了,天下之事,分久必合,合久必分,人类社会尚且如此,更何况社会活动的产物——开发框架呢。我这儿的意思嘛,也就是鼓吹鼓吹大家别乱跑看好队伍站进去然后尽量始终如一罢了:) 这点Ruby社区做得很好,起码就我所知ror独大。而Python么,也许因为牛人泛滥,分家之事为之过多了。

关于贡献。就说Django吧,如果某些意见在trunk通不过,何不试试建个新的分支呢?不可调和很大程度上是因为沟通的不够,那么一个实际的实现实例也许能让他人接受自己的想法,又或也许发现他人不接受的原因。编程世界相对而言还是一个比较开明的世界,或对或错一般来说比较明确,一个开放的社区对于对的东西应该保持一种包容接受的态度。但假如仍然无理由的拒绝,那么另起炉灶应该是一个比较好的解决办法。当然这都是我随便拍着脑袋想出来的,对于实际情况我还是小白一个……

最后,怎么说呢,Django是有不完善的地方,这东西随着使用的深入会慢慢凸现出来。我真正使用Django的时间也就半年左右吧,现在只能说是稍有了解,发现的问题肯定是没有您那么深入的。所以说的话么,有的也许在你看来很幼稚,请见笑。至于Uliweb有时间我也会再看看,我也很想知道您说的更灵活的app是什么概念。虽然现在我还是一个忠实的Django用户,兴许过阵子就成为uliweb的粉丝了也说不定呵呵。

谈谈我对Uliweb的看法

内Py大牛limodou写了个Uliweb —— 一个类似Django的Web框架。考虑到去年刚刚接触Python时看了不少他在javaeye上分享的经验,觉得应该是个不错的东西吧,于是便复制了一份下来看看。

在看了大致的介绍以后,突然间没了兴趣。对于我来说,一个好的Web框架的意义是,一个不错的ORM来处理数据库连接,一套不错的HTTP库来处理包装HTTP请求和回应,一套PyInHTML的template系统,至于中间的逻辑处理,这是根据各种不同的需求来定的,能有多灵活最好就有多灵活,当然,有一套Debug系统是更好不过的了。再来看Uliweb,ORM使用了SQLAlchemy,HTTP使用了WebOb,模板用了Web2py的,Debug使用了Werkzeug提供的功能。咋一看不错,啥功能都有了,但是再仔细一想,那么这个框架又做了什么呢?我相信像limodou这样的牛人肯定是会加一些自己的东西在里面的,但我也相信在这些重量级的功能面前,这些附加物所占有的比例也不会太大,甚至更偏向于个人喜好,换一个开发人员用起来也许反而会觉得别扭。

说的恶毒一点,Uliweb又是一个TurboGears,一个大杂烩。现在基于Python的Web框架越来越多,而就我本人的意愿而言,竞争是希望有的,但是大统也是希望的。从实际的角度说,我更希望所有人都为同一个目的共同奋斗,避免竞争中资源的浪费,北京奥运还说“同一个世界同一个梦醒”嘞……Django也好web2py也好其他等等也好,如果在使用中遇见让自己不爽的地方,还是有不少办法反馈给项目的,这就是至少是我所希望的开源。如果说,大部分的老手在使用过几个框架后不爽了都跑出来自立门户的话,这场面该有多么混乱……在我们觉得不要重复造轮子的情况下,类似的轮子还是在不停的造出来……

如果硬说还需要一个框架的话,我更希望能够有一个插件系统,在处理完基本绑定后,可以自由选择ORM啊templating啊之类的实现,满足各人的灵活需求。当某个轮子发展到瓶颈时,只需要制造基本的新轮子就行,而框架本身不需要做太大的变化。理想总是美好的,不是吗 =_,=

以上只是我自己的一点想法,也许对于相关开发人员来说相当刺耳,但是我这人太实际有话就说了,也有可能是身为一个Django user的偏执之言,如有冒犯敬请见谅。