还是关于Uliweb，刚刚回复了limodou的新的留言：
发现你好像误解我的意思了，我并不是在和你争论Uliweb和Django那个更优秀，因为这个各人有各人的见解，不依靠武力（？）手段很难得到口径上的统一。我评论Uliweb其实主要还是表达一下自己对某种新框架的向往，因为发现目前Uliweb并不能达到我的要求。
我也不反对造轮子，但是目前吧Uliweb对我来说就不像是轮子，更像是车子。举个例子，某人搞了一家汽车厂，但是造的车的各个部件都是从其他不同 工厂里拿来的，那他造出来的车最初肯定是颇受争议的，而且有一个问题，这个车是缺少自己核心的技术的，其他人采用相同的法子也可以弄出类似的车子来竞争。 但是可以肯定的是，只要不在这最初的一步上驻足自封，而是发展自有的核心技术，那么在争议之后这厂子仍然能继续生存下去，甚至打出自己的品牌。
就Uliweb来说，我不知道现在limodou大牛你现在引入了多少自有的核心组件，但是应该也会有蛮多人和我一样由于看不到这些核心特性而口吐 唾沫星子的。你别太在意就行。既然你觉得Django团队并不那么容易接受，请坚持你现在的这条道路。希望将来Uliweb能够有足够多的理由让更多的 Django用户叛变过来：P
那我自己所希望看到的框架是什么样的呢？说起来其实蛮简单的，甚至谈不上框架，只是一个Pluggable的各种框架的连接器。那这个“连接器”有什么特点呢？
- 各组件之间搭配的可定制性。作为一个开发人员，可以自定义开发时使用哪种模板渲染系统、哪种ORM系统等等。比如你可以在全局定义使用jinja2的模板，然后在一个app下定义使用mako的模板。一切都是可以灵活配置的。
- 其他框架下的应用的复用性。这将最大化一个app的应用范围，在这套“连接器”的控制下，可以方便的把django的app或者uliweb的app等等集成进来。
看上去是很美好的不是么，挺朴素的功能，但是实现起来也许就不是那么容易的事了。兴许某一天我会发现这么一个满足条件的框架，又兴许某天我自己耐不住了自个儿尝试去实现这么个东西。但是就目前嘛，还是先拿着Django好好学习去吧，还有很多值得我学习的东西呢。
我也不是为了争uliweb要比django强大，我也说了uliweb有自已的优势，而且我认为比django强的，但django也有它的优势。而且我也在邮件列表中多次声明，每个框架代表一种哲学，不同的哲学引来不同的用户，所以我离开django也可以说是我的哲学与django的哲学区别越来越多造成的。
至于造轮的问题，因此我还是建议你有时间多了解一下uliweb。在今年9.5日的大会上我列举了自已创建的轮子的例子，比如：
整个核心的处理完全是自已写的，它是一个框架的灵魂，负责整个框架的启动，组件管理(app管理)，配置管理，request和response处理，middleware的处理，这是每个框架不同于其它框架的核心，是无法复制的。如果只是简单的复制，那么这个框架存在的意义就没有了。其中整个app的详细支持是借鉴了django的思路，但是由我完善的。还有象view的处理，借鉴了web2py的思路，但是自已实现的。详细代码可以见uliweb.core.SimpleFrame.py.
还有许多的模块是我自已写的：
1. web2py的模板，已经被我改造增加了象编译文件目录支持，自定义tag支持，block的支持，这些都是原模板没有了，已经是uliweb化的组件了。
2.dispatch模块，完全是自已写的，实现类似于django signal的功能。但是整个实现是从ulipad发展来的，没有照搬任何人的东西。
3.i18n也是自已写的，是从ulipad发展来的。
4.weto是在我发现beaker这个session库有问题之后重写的，完全是uliweb的东西。
5.contrib下的所有组件都是我自已写的。
6.pyini完全是自已构思创造出来的，用于处理uliweb的配置文件。
7.orm这块是从头一点点构建的，也是一个框架很重要的部分。
8.form库也是自已一点点写的。
9.url映射的处理机制是使用了werkzeug的route为基础实现的，但是只是使用了它的基本功能，主要功能是uliweb实现的。
一个框架主要完成的功能其实不外乎：url处理，request, response，view，orm，组件管理，配置管理，提供一些实用的扩展。因此，你可以看到，从架构设计，从组件的实现，许多方面都有uliweb自已的实现，甚至完全是uliweb自已的实现。因此从web2py，从django，从werkzeug，从sqlalchemy更多不是简单的引用，而是思想的借鉴，是更多的封装。
所以，许多东西并不是简单了解就好象明白的。这是我想要澄清的地方。别人不认可uliweb没关系，很正常。但是我只是希望，评论一个东西首先要对它多少深入地了解一下，哪怕与作者交流一下也好，而是不看些表面。不仅从合理客观的角度来谈论一件事，更是不会误导别人。所以uliweb绝不是简单地组装出来的一个东西，它有自已特性甚至独一无二的东西。许多人一谈uliweb，就是从重装造轮的角度，但是他们并不了解许多uliweb上的设计的东西，也基本上没有在技术细节上的讨论，谈得很泛泛。这样对谁都不是公平的。
你所说的框架其实目前pylons和tg都差不多，而uliweb也是可以，django也是可以，只不过pylons和tg可能从组件上可以直接选择，而uliweb,django是可以自已定制开发，不能直接使用。而且你所说的更接近于某些人更偏重于自已去建，比如这篇文章：
http://pythonpaste.org/webob/do-it-yourself.html
自已建是没有问题。因此框架更多是给那些不希望，甚至不能够自已来做这件事的人准备的。但是自已建，可能需要了解的东西更多，正如我在构建uliweb过程中，我学到了比以前简单使用框架更多的东西，我甚至做了许多以前不知道自已还可以做的事情。各有各的乐趣。
展开回复(1)
其实现在我不是太清楚你列举这么多轮子是什么意图……第一篇文章我应该承认过我是很粗略的看了Uliweb后发表的第一感受，可是你这么较真让我觉得挺奇怪的，那万一又有许多人和我一样随便看两眼便出来批判批判，你的时间岂不是都浪费了？第一感受是片面的主观的是常见的事情，过于较真反而会显露气场的不足。上一篇回复我举的车厂的例子，其实也就是说这种小事不用太去理会。是金子总是会发光的，我吐完口水也许哪天会乖乖的把口水擦擦干净又屁颠屁颠地跟上来也说不定吧。所以，关于Uliweb的孰是孰非咱就讨论到这行不？
个么下面开始讨论理想框架的事。又是第一眼感受，呵呵，请拍砖。刚刚略过一眼Pylons，感觉它的定制是在项目级别的。而我说的是更纯粹的定制，可以细化到各个模块。这样就可以达到app级别的随意复用。之前也看到过让Django支持其他模板系统的文章，可是这不是框架的原生支持，只算是hack，对于希望代码统一管理的我来说并不是很好的选择。所以不知limodou大牛在这方面有没有什么建议？
讲了这么多轮子就是为了回答你uliweb的核心技术有哪些，因为从你的文字中你是认为uliweb只不过是简单的组装而已。
至于你对pylons的感受，它就是在创建项目时可以进行组件的定制。因为每个项目都是独特的，在创建项目时定制是合理的。
如果说django中更换组件这个只有靠自已去实践了，应该可以做到。
展开回复(1)
Sigh，我喜欢站在客户的角度说话，如果换作开发者角度就不会这么吹毛求疵了。而且我也没说Uliweb就是简单组装，我再三强调了这是第一感觉。不过既然我说了不说这事儿了，那么就这样着吧……
Pylons的做法我并不是很满意。这种自定义对于一个一直使用Pylons的用户来说没有意义，因为他已经习惯了某种搭配。那么我说的自定义是什么呢？以template为例，如果页面呈现是以widget方式为主，我会选择Django的tag，如果页面需要表达复杂逻辑，这时候Django的模板就会显得很繁琐，也许换用一个其他的模板会比较方便一点。又比如说app，假使我说的框架支持Uliweb的处理方式，我在现在一个以Django为主体的项目中想使用一个Uliweb的app的话，在简单配置以后就能使用，这将是一件让人很愉悦的事情。这样的框架可以说是一个万能胶，能粘就粘，如果粘的不好，再去考虑寻找其他替代或者是重新自创。
最后关于Django更换组件，如果不是框架提供的而且不是缺它不可的东西，我一般是不愿意去做hack的。我心目中的统一，其实是对DRY的一种诠释。就Python的灵活性来说，自己去对框架做hack都不是很难的事情，对个人来说这没有重复，但是对所有和你需求一致的人来说这又是一件重复制造的过程。所以我更希望能有一个框架来处理这个事情。
一般一个框架都是自成体系，比如模板，ORM，View，架构等，它们之间会有交互，而这些交互的标准就是一个框架的标准，不同的框架在设计时有些可能比较接近，有些则不完全相同。而且让这些标准运行起来的机制可能也不相同。总是存在许多不同的东西，原因就是没有一个统一到各个层面的开发框架的标准。wsgi是一个标准，但也很底层，解决不了模板，ORM，等的问题。所以这样的灵活的框架很难实现，现在也有没。有些框架能做的也是要考虑组件的适配性而产生的灵活性，是需要一定的努力才可以实现的。所以许多工作只能靠自已来完成。不过，你的做法也要求你学习很多的东西，比如django的模板，uliweb的app。当然不是坏事。web开发本身就是复杂的。每种框架可能都有它的局限性，没局限的可能就是那么不做什么事的框架。
使用框架一种是你适应它，另一种是它适应你。你适应它容易，让它适应你难。而让它适应你却是自身积累的一种表现。比如你有你的方式，为什么不去改造框架按你的方式来工作呢？就和你想要的灵活的框架一样。而且一旦成功对自已是有好处的。而且任何框架都是可以被改造的，只不过框架对改造的支持不同，有些改造起来会容易一些。uliweb在许多设计上就是考虑了重用性，可配性，灵活性，比如：app的管理，配置处理机制，dispatch机制。许多设计是从ulipad的思想发展而来。而ulipad就是许许多多的mixin的组件拼出来的，扩展强力很强。
我看待一个框架不会只看表面，因为那样看到的基本上只是一些基础的功能，大部分的框架大同小异。我看的是它的实现，比如url是如何设计，是何种框架类型，使用了哪些组件，开发模式是什么，主导的设计思想是什么。这些才真正是框架之间差异的重点。
来插嘴喽,二位休息下先.
一个层面解决不了的问题,应该上升到更高的层面.
摒弃某个底层部分的不同细节,然后更清晰地描述出或者说找出问题的本质.
最后对这个抽象出来的问题做出解决.
这样貌似好搞一点啦.
就二位而言,两位是否阐述一下自己的意图:
用一句话概括和对方开启话题的原因?
limodou老大先来说说,
因为您先回应jay哥"谈谈我对Uliweb的看法"导致了整个话题展开...
jay哥,
limodou老大说完,先和他握个手嘎.然后再做您的概括.
p.s 和事佬之道,在于一人打一棒子,一人给一甜糖...
我是来和稀泥的.