sqlalchemy、storm和web2py dal的比较报告
刘鑫
分割线内内容仅代表个人意见，与所供职企业及参与社区无关。
===================================
X 从很早的时候就出现各种数据库访问错误。包括链接数占用过多，死锁，
僵尸事务等。本周我集中梳理了一遍代码。我认为，虽然数据库设计方面有诸多
不合理之处，但是这些不合理主要影响业务错误，造成 X 性能和使用上的
问题是因为使用的ORM框架 storm 有严重的缺陷。
首先，storm 对数据库架构的同步有非常奇怪的设定。它不自动同步表结构，却插
手外键关联关系。强制要求外键必须都是级联更新、级联删除、set null。且不说
其设定中有自相矛盾之处，本身在MIS系统中做级联删除就是一件很危险的事——除
了系统维护、分表，MIS系统不应该删除任何数据。 storm 从一开始设计恐怕就没
有考虑企业级应用，但是对于web 开放式应用，storm 对外键的依赖又太笨重了。
其次，storm 在联接数据库后应该会有 DDL 操作（即修改数据库结构）或独占锁
定事务，此推断的证据在于用 storm 联接到 S 库后， S 无法进行
vacuumdb -a -f 处理。而根据 Postgres 手册，PG只有在遇到有链接正在进行
DDL 操作时，才会产生库级锁，造成 vacuum 操作无法进行（或手工建立一个隔离
级别相当的事务锁定）。作为世界上并发能力最强的数据库产品，正常的数据访问
操作与 vacuum 根本不会冲突，热处理资源回收正是 PG 独到的特性。这样造成了
X 应用频繁用光所有的链接数，还在数据库服务器遗留僵尸进程。我观察到
有僵死十几二十天没有完成过的 X 链接，这应该是因为同时多个 storm 链
接提交错误的锁定关系，造成死锁。
第三，storm 如果可以象 DAL 那样，明确设定不同步数据库，以上问题至少可以
解决一半，但是它没有链接配置参数。这造成了我们对其出现的问题无法进行友好
的调整。现在同事在 X 的 controll 层添加了强制的 commit 操作，一定
程度上减少了死链，但是我仍然观察到有点击 X 页面（在测试环境下）无
法响应，甚至造成数据库服务器闪断重启的现象，对于同时运营三十几个数据库的
数据库服务器，这是非常大的安全隐患。
昨天我尝试将 X 的数据库访问层迁移至 web2py DAL，经过一天尝试，总结
出以下的问题：
第一，DAL 缺少精确实数计算类型，它不支持 Numeric 或 Decimal，只能用
double，这是一个相当大的安全隐患，对于涉及财会计算的应用，使用浮点数是一
种很不严肃的作法。
第二，DAL 不支持数组和大数据类型，此类字段在 X 中有几处应用。
第三，DAL 对原生SQL的支持比较初级，虽然也可以使用，但是有时需要兼顾开发
速度，希望可以组合使用的时候，就会受限。
以上问题不是不能解决，但是需要修改 DAL 本身。虽然我一直有计划改造 DAL，
fork 一个对 PG 有良好支持的分支出来。但是这显然需要更多的开发时间。
昨天我详细查阅了一下 sqlalchemy 的文档，进行了一些简单的尝试，感觉这个
ORM 框架比较符合我们的需求：
第一，sqlachemy 对数据库链接的隔离级别和事务有良好的控制，默认也不会去尝
试DDL操作。
第二，sqlachemy 有非常丰富的数据类型支持，包括BLOB，Decimal/Numeric，以
及为 PG 特别定制的数组类型。
第三，sqlachemy 的查询类似 DAL （很可能DAL学习自sqlachemy)，对各种查询操
作有良好的支持，还可以嵌入 SQL 片段，也可以方便的直接传入 SQL。
第四，sqlachemy 其实并不难学，它的功能虽然丰富，但是只掌握自己要用到的部
分即可，不需要完全学会，上手还是很简单的。
第五，文档比 storm 完整的多，而且现在仍在活跃开发。
第六，数据存储模型与业务模型分离，虽然看起来有重复劳动，但是对于一个需要
长期维护的企业应用项目，这是正确和严肃的作法。
第七，对特定数据库的特性有良好的支持，还可以扩展。
在使用 sqlachemy 时，我们还可以结合 web2py 原有的一些优秀工具，例如广泛
用于 DAL 的storage类型，这是一个类似 JS Object 的智能对象类型，很适合动
态结构的数据对象。
对于 X 项目的数据访问层重构，我评估工作量至少在一周左右。如果全部
换用 sqlachemy ，可以一劳永逸的解决数据库访问的问题，甚至 S 的后续版
本，我也建议尝试使用这个框架，毕竟这比 hack dal 要方便一些。
sqlachemy 当前的稳定版本是 0.5.6 ，我昨晚试验了开发中的 0.6 ，发现功能还
没有完整实现，现在还不能实用。
===================================
--
光见贼吃肉，没见贼挨打。
……
劉鑫
March.Liu
smallfish
--
如果不能改变结果 那就完善过程
http://hi.baidu.com/smallfish_xy
http://blog.csdn.net/smallfish_xy
limodou
uliweb中的ORM就是基于sqlalchemy做的。不过目前没有用到它的session。
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou
way wrong
Jim Zhan
On Sep 25, 11:55 am, 刘鑫 <march....@gmail.com> wrote:
> 工作项目报告，所以抹掉项目名先，以"X"代之。
>
> 分割线内内容仅代表个人意见，与所供职企业及参与社区无关。
>
> ===================================
>
> X 从很早的时候就出现各种数据库访问错误。包括链接数占用过多，死锁，
> 僵尸事务等。本周我集中梳理了一遍代码。我认为，虽然数据库设计方面有诸多
> 不合理之处，但是这些不合理主要影响业务错误，造成 X 性能和使用上的
> 问题是因为使用的ORM框架 storm 有严重的缺陷。
>
> 首先，storm 对数据库架构的同步有非常奇怪的设定。它不自动同步表结构，却插
> 手外键关联关系。强制要求外键必须都是级联更新、级联删除、set null。且不说
> 其设定中有自相矛盾之处，本身在MIS系统中做级联删除就是一件很危险的事----除
> ......
>
> 劉鑫
> March.Liu
四不象
刘鑫
这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化……
四不象
@@
我开始想试试pg的 不过发现mysql一个现有的库 转到pg 一点也不容易。。弄了1 2天 放弃了。。
关键是facebook这样的都选的是mysql。。。
google也是为mysql出过patch，没看到他为pg出patch（也许有 没看到）
刘鑫
也得看服务器吧。。
我开始想试试pg的 不过发现mysql一个现有的库 转到pg 一点也不容易。。弄了1 2天 放弃了。。
关键是facebook这样的都选的是mysql。。。
肯定跟硬件有关，不过我们这边儿的兄弟部门用的服务器也都挺好，NB到4倍以上性能的硬件……
其实PG的大型应用也很多。只是我们国内介绍的少而已。一个逾二十年历史（http://www.phpx.com/man/Pgsql/history.html）的主流数据库产品，在用户群方面，还是很有说服力的：）。
google也是为mysql出过patch，没看到他为pg出patch（也许有 没看到）2009/9/25 刘鑫 <marc...@gmail.com>
2009/9/25 四不象 <tabris17.cn@gmail.com>
这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化……
Leo Jay
> 也得看服务器吧。。
> 我开始想试试pg的 不过发现mysql一个现有的库 转到pg 一点也不容易。。弄了1 2天 放弃了。。
>
> 关键是facebook这样的都选的是mysql。。。
技术力量不一样的，人家不仅用，还有本事做改进。
> google也是为mysql出过patch，没看到他为pg出patch（也许有 没看到）
>
--
Best Regards,
Leo Jay
四不象
----- Original Message -----From: @@
刘鑫
最后还是决定用mysql了，pg以前没用过，还是先学习下再进行实际应用吧。不过我决定把某表主键从BIGINT改回INT了，如果真的碰到INT主键耗尽，那就说明该换数据库了:)
数据库的选项也是个比较重要的事，支持谨慎选择，积极比较的作法：）。
Sent: Friday, September 25, 2009 2:34 PMSubject: [CPyUG:101845] Re: sqlalchemy、storm和web2py dal的比较报告也得看服务器吧。。
我开始想试试pg的 不过发现mysql一个现有的库 转到pg 一点也不容易。。弄了1 2天 放弃了。。
关键是facebook这样的都选的是mysql。。。
google也是为mysql出过patch，没看到他为pg出patch（也许有 没看到）
2009/9/25 刘鑫 <marc...@gmail.com>
2009/9/25 四不象 <tabris17.cn@gmail.com>
这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化……
way wrong
接下来，开始尝试刘鑫同学大力鼓吹的pgSQL.
smallfish
Jiahua Huang
leopay
不过pg的确用的很爽, 自己感觉用起来比mysql 靠普
====================================
以上观点仅代表自己的观点和社区无关
suhanwu
近期也计划在个人的项目上用PG.
不过公司一直用Oracle.
On 9月25日, 下午10时11分, leopay <leo...@gmail.com> wrote:
> 偶也用vim, 其实一直想尝试emacs, 但是担心vim转到emacs的成本太高
> 不过pg的确用的很爽, 自己感觉用起来比mysql 靠普
>
> ====================================
> 以上观点仅代表自己的观点和社区无关
>
> 2009/9/25 Jiahua Huang <jhuangjia...@gmail.com>
>
>
>
> > 挺小鱼～
>
> > 2009/9/25 smallfish <smallfish...@gmail.com>
>
> >> 坚持自己，偶用VIM！- 隐藏被引用文字 -
>
> - 显示引用的文字 -
TodJiang
公司内部的Trac 用Postgres 时候， 发现有时候出现大量线程堵塞http://trac.edgewall.org/ticket/
8443， 目前trac项目还没fix。
后来发现公司内部的同事开代理上就会出现那个问题， 具体原因还在寻找。
MySQL的文档还是比较多， 性能需要自己实际动手才知道哪个好。
On 9月25日, 下午2时21分, 刘鑫 <march....@gmail.com> wrote:
> 2009/9/25 四不象 <tabris17...@gmail.com>
>
> > 这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
>
> 跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
> 我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化......
>
>
>
>
>
> > ----- Original Message -----
>
> > *From:* way wrong <wrongwa...@gmail.com>
> > *To:* pyth...@googlegroups.com
> > *Sent:* Friday, September 25, 2009 1:22 PM
> > *Subject:* [CPyUG:101833] Re: sqlalchemy、storm和web2py dal的比较报告
>
> > 正考虑使用PostgreSQL中，这么好的资料，俺收藏了
>
> > 2009/9/25 刘鑫 <march....@gmail.com>
>
> >> 工作项目报告，所以抹掉项目名先，以"X"代之。
>
> >> 分割线内内容仅代表个人意见，与所供职企业及参与社区无关。
>
> >> ===================================
>
> >> X 从很早的时候就出现各种数据库访问错误。包括链接数占用过多，死锁，
> >> 僵尸事务等。本周我集中梳理了一遍代码。我认为，虽然数据库设计方面有诸多
> >> 不合理之处，但是这些不合理主要影响业务错误，造成 X 性能和使用上的
> >> 问题是因为使用的ORM框架 storm 有严重的缺陷。
>
> >> 首先，storm 对数据库架构的同步有非常奇怪的设定。它不自动同步表结构，却插
> >> 手外键关联关系。强制要求外键必须都是级联更新、级联删除、set null。且不说
> >> 其设定中有自相矛盾之处，本身在MIS系统中做级联删除就是一件很危险的事----除
> >> ......
>
> >> 劉鑫
> >> March.Liu
>
> --
> 光见贼吃肉，没见贼挨打。
> ......
>
> 劉鑫
> March.Liu
Leo Jay
> PG的文档太少， 我之前想看看PG优化的东西， 网上search半天， 找到实用的也不太多。
> 公司内部的Trac 用Postgres 时候， 发现有时候出现大量线程堵塞http://trac.edgewall.org/ticket/
> 8443， 目前trac项目还没fix。
trac问题不少，psycopg2的开发者好像就很不爽：
http://www.initd.org/tracker/psycopg/wiki/PsycopgTwo
> 后来发现公司内部的同事开代理上就会出现那个问题， 具体原因还在寻找。
>
> MySQL的文档还是比较多， 性能需要自己实际动手才知道哪个好。
Jerry
错的米缸 --
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
Jerry
（并非嘲笑FriendFeed或MySQL）
On Sep 25, 2:21 pm, 刘鑫 <march....@gmail.com> wrote:
> 2009/9/25 四不象 <tabris17...@gmail.com>
>
> > 这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
>
> 跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
> 我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化......
>
>
>
>
>
> > ----- Original Message -----
>
> > *From:* way wrong <wrongwa...@gmail.com>
> > *To:* pyth...@googlegroups.com
> > *Sent:* Friday, September 25, 2009 1:22 PM
> > *Subject:* [CPyUG:101833] Re: sqlalchemy、storm和web2py dal的比较报告
>
> > 正考虑使用PostgreSQL中，这么好的资料，俺收藏了
>
> > 2009/9/25 刘鑫 <march....@gmail.com>
>
> >> 工作项目报告，所以抹掉项目名先，以"X"代之。
>
> >> 分割线内内容仅代表个人意见，与所供职企业及参与社区无关。
>
> >> ===================================
>
> >> X 从很早的时候就出现各种数据库访问错误。包括链接数占用过多，死锁，
> >> 僵尸事务等。本周我集中梳理了一遍代码。我认为，虽然数据库设计方面有诸多
> >> 不合理之处，但是这些不合理主要影响业务错误，造成 X 性能和使用上的
> >> 问题是因为使用的ORM框架 storm 有严重的缺陷。
>
> >> 首先，storm 对数据库架构的同步有非常奇怪的设定。它不自动同步表结构，却插
> >> 手外键关联关系。强制要求外键必须都是级联更新、级联删除、set null。且不说
> >> 其设定中有自相矛盾之处，本身在MIS系统中做级联删除就是一件很危险的事----除
> >> ......
>
> >> 劉鑫
> >> March.Liu
>
> --
> 光见贼吃肉，没见贼挨打。
> ......
>
> 劉鑫
> March.Liu
Jerry
war，这儿再给一个 --
http://stackoverflow.com/questions/110927/do-you-recommend-postgresql-over-mysql
Jerry
光风
ronin
料，说是select性能比myisam差很多，我想现在web2应用大多数操作都会以myisam，这样的话会不会pg性能很差？
On 9月25日, 下午2时21分, 刘鑫 <march....@gmail.com> wrote:
> 2009/9/25 四不象 <tabris17...@gmail.com>
>
> > 这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
>
> 跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
> 我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化......
>
>
>
>
>
> > ----- Original Message -----
>
> > *From:* way wrong <wrongwa...@gmail.com>
> > *To:* pyth...@googlegroups.com
> > *Sent:* Friday, September 25, 2009 1:22 PM
> > *Subject:* [CPyUG:101833] Re: sqlalchemy、storm和web2py dal的比较报告
>
> > 正考虑使用PostgreSQL中，这么好的资料，俺收藏了
>
> > 2009/9/25 刘鑫 <march....@gmail.com>
>
> >> 工作项目报告，所以抹掉项目名先，以"X"代之。
>
> >> 分割线内内容仅代表个人意见，与所供职企业及参与社区无关。
>
> >> ===================================
>
> >> X 从很早的时候就出现各种数据库访问错误。包括链接数占用过多，死锁，
> >> 僵尸事务等。本周我集中梳理了一遍代码。我认为，虽然数据库设计方面有诸多
> >> 不合理之处，但是这些不合理主要影响业务错误，造成 X 性能和使用上的
> >> 问题是因为使用的ORM框架 storm 有严重的缺陷。
>
> >> 首先，storm 对数据库架构的同步有非常奇怪的设定。它不自动同步表结构，却插
> >> 手外键关联关系。强制要求外键必须都是级联更新、级联删除、set null。且不说
> >> 其设定中有自相矛盾之处，本身在MIS系统中做级联删除就是一件很危险的事----除
> >> ......
>
> >> 劉鑫
> >> March.Liu
>
> --
> 光见贼吃肉，没见贼挨打。
> ......
>
> 劉鑫
> March.Liu
limodou
> 这段时间准备为项目选型，已经决定有用python，框架用web2py（uliweb好像还没有人用吧，看了PPT很感兴趣),数据库我看了网上资
> 料，说是select性能比myisam差很多，我想现在web2应用大多数操作都会以myisam，这样的话会不会pg性能很差？
>
uliweb还没发布呢？现在用的确不合适，目前更适合学习和做一些小型的项目。
ronin
巨汗，没有找到修改帖子功能
On 9月25日, 下午1时22分, way wrong <wrongwa...@gmail.com> wrote:
> 正考虑使用PostgreSQL中，这么好的资料，俺收藏了
>
> 2009/9/25 刘鑫 <march....@gmail.com>
limodou
> limodou：
> 你好
> 什么时候能出来？打算搞个类似jayaeye.com这样的网站，你觉得web2py还是django比较好，我是看了你的uliweb的ppt，感觉
> web2py比较好的，我个人没有接触过，以前都是用php的。每天都去你的博客看，挺佩服你的
>
目前uliweb的状态是：
已经完成的功能：
核心，包括app的管理，view，模板的加载，url映射
模板
i18n
form
dispatch
其它的完成组件
orm需要进一步完善
staticfiles
upload
template
session
不稳定的：
象cache没有太测试过，因为我做的项目比较少还没怎么用，使用的是beaker库
ORM,基于sqlalchemy改造，正在完善中，需要比较大的应用进行验证。正用在我开发的doto中。
没做的：
性能，这个也不是很好比较
部署，我只在GAE和mod_wsgi上部署过。
因此是否成熟主要看你打算如何使用uliweb。如果想尽量使用uliweb的组件，如ORM，的确不完善。如果这块不打算用的话，基本上就可以了。
web2py与django是两种思路。应该说uliweb与django比较接近。web2py的app是运行单位，在实现app的复用时我认为比较麻烦。但是好处就是互相隔离。这一点有些象java的应用，一个应用就是一个war包，可以部署在一个容器中。而uliweb或django基本上一次只能部署一个项目，当然这是符合大部分情况的。另外就是web2py自动做了一些事情，比如导入，而django大部分要导入。但是web2py有些地方比较不好弄，比如：
一个就是前面提到的app间的复用问题，
还有象模板不支持块的覆盖，不如Django方便，虽然我提交了我的修改，但是没有被web2py采用，
还有象url的设置，我认为uliweb是最方便的
还有有些理念我不是很赞同的，当然可能不算是问题，如兼容性和所谓的0配置，这样会造成一些比较不方便的地方，而这些却在最近的邮件列表中被作者所强调，遗憾
当然web2py也有一些不错的地方：
模板的自动套用我认为web2py还是方便
它的admin功能还不错，可以直接在线编辑。但是这里还是有一个问题，因为它是使用exec来执行controller代码，所以服务器一般不需要自动重启，修过的代码就会生效，但是这只是影响controller代码，如果还导入了其它的模块就很麻烦，需要改为reload()，这种方式有时会有奇怪的问题。不如自动重启服务器的好
web2py有T2,T3这种东西，不过因为有段时间没有跟踪，所以也不是很清楚，据说可以简化某些应用
反正是有利有弊。所以我为什么创建uliweb，不过uliweb现在的确成熟度不够。如果不好判断，不如在列表中再比较分析一番，不过国内使用web2py的还是少。从个人感觉，web2py在某些功能上不错，但整体性还是有些不足。
limodou
>
> 我觉得ORM可以不用吧，应该是sqlalchemy可以直接用，cache应该是很关键的东西，我用memcached，至于性能是个敏感问题，这个
> 需要大型项目来验证，还有IDE支持我想也是个关键（我一般用eclipse），如果没有容易上手的工具肯定事倍功半，我的网站是关于电脑技术网站，功
> 能类似于CMS，有想法去试一些比较少人用的东西，比如uliweb和pg数据库
cache目前在uliweb中是使用beaker模块，它支持memcached，不过我没有用过。我现在环境都没装memcached。性能的话，因为我目前更关注的是功能，而且如何去测试我也没有更好的方法。如果只是写一个hello之类的去测试，因为功能太简单，基本上我认为用处不大。但是测试其它的，就涉及到许多的东西，甚至包括数据库。不知道有没有基准的程序可以方便地去测试。
IDE的支持要看想要支持些什么东西。目前在ulipad中我没有对uliweb做任何的支持，感觉也没有什么问题。
如果能用上uliweb那是非常欢迎的。
Jiahua Huang
林刚
On 9月26日, 下午2时17分, Jiahua Huang <jhuangjia...@gmail.com> wrote:
> 貌似许多都是说 MySQL 当键值对数据库用，并不比 bsddb 加个网络层慢
>
> 2009/9/26 Jerry <jerryji1...@gmail.com>
张沈鹏
刘鑫
说是select性能比myisam差很多，我想现在web2应用大多数操作都会以select为主，这样的话会不会pg性能很差？
MySQL在一些应用场景快是很正常的，它本来就是为这类场景设计的。在其它应用场合有比它适用的产品也是正常的。IT业已经发展成一个很大的产业，涉及的应用领域也丰富多彩，多了解一些不同的技术，为自己应用组合适用的工具，有助于我们做的更好。
jejwe
limodou
> 试下Geniusql呢? 再做个测评。
最早uliweb的ORM就是基于geniusql，无奈用户太少，邮件列表基本上没人，后来转到sqlalchemy上去了。
Jiahua Huang
limodou
> 觉得简单应用还是 sqlobject 方便，
> 最起码弄个类就能工作了，
> 不需要再重复手工定义一遍数据映射
sqlalchemy也可以啊。
Jiahua Huang
limodou
> 可是看过的项目使用 sqlalchemy 的几乎全有手工定义数据映射
>
有一个autoload还是什么的参数，不用定义直接映射。
Jiahua Huang
limodou
> 顶木头～
> 可有啥负面影响？
>
没有吧。我没用过。可能有些象索引，唯一和缺省值什么的自动探测生成的可能不精确或缺失吧。
诚子
Jiahua Huang
limodou
> 嫌SqlAlchemy不好使的都用Elixir吧
>
我也订阅了Elixir的邮件列表，没多少邮件，感觉用的也不多。因为sqlalchemy自已也有ORM的封装，所以可能用Elixir的不多吧。
诚子
limodou
诚子
--
my.unix-center.net/~WeiZhicheng
Zoom.Quiet
> 我想组装一个适合自己的Framework limodou大哥有什么建议?
>
InfoQ: Python Web框架UliWeb开发进展
http://www.infoq.com/cn/news/2008/08/python--uliweb
参考 UliPad 的选择之路...
--
http://zoomquiet.org 人生苦短? Pythonic!
工作的层次(依靠谱程度从低到高)=有做-＞做完-＞做对-＞做好-＞帮助他人做好
limodou
1. 要不要组装的判断。你的需求是什么？现有的框架有没有合适的，有没有近似满足的，有没有可以在上面进行扩展的，你有没有时间和能力去维护一个框架。也有些人建议不去使用框架，而是使用工具。那么这也是一种做法。我们做框架的目的就是为了复用，不然直接做一个个的应用就好了。所以做框架比做应用要更多的考虑灵活性，适用性，扩展性等特点。
2. 如果经过判断的确没有满足条件的框架或方法，那么选取你认为满意的组件开始搭建。
基本功能要考虑：
1. 框架结构，比如：目录安排，组织方式，是mvc还是mvt，然后组件如何划分，如何管理
2. URL映射机制，比如：django方式的，还是uliweb方式的，还是web.py方式的，还是web2py方式的
3. 配置管理，如何管理你的配置信息，使用py源文件，还是ini，还是象uliweb中的pyini，组件的配置如何管理
4. 运行机制，比如：使用wsgi，还是其它的方式，一个请求如何被处理，如何被应答，与下面的request和response有关
5. 开发环境，比如：是否提供开发服务器，是不是支持多线程，是不是可以reload，还是象web2py那样不需要
6. 部署环境
7. Reqeust, Response的处理，如何从web server得到一个request, 如何应答一个response
8. 静态文件的处理机制
9. 文件上传及Form提交处理
10. 模板系统
有了以上基本内容就包括了：架构设计，开发设计，部署设计。
然后你可以选择一些实用的库，比如：
2. URL映射
5. 开发环境
6. 部署环境
7. Reqeust, Response的处理
8. 静态文件的处理机制
10. 模板系统
都可以使用werkzeug完成
当然，上面的象静态文件，模板系统都可以再换成其它的。剩下的象：
1. 框架结构
3. 配置管理
4. 运行机制
9. 文件上传及Form提交处理
多半要自已做了，这块是框架的灵魂或核心（9不算）。
上面只是基本的框架功能，其它的还有象：
11. session, cache
12. ORM
13. i18n
14. admin
15. 命令行工具
16. 扩展设计，如:django的signal, uliweb的dispatch，其它的扩展机制
17. 实用工具或模块集，比如:django的feed, comment, auth等,uliweb的staticfiles,
template, upload, mootools, yaml等app
18. 其它暂时没想到的
对于上面的功能，并不是框架必须的，但是可能随着框架的完善和成熟，会不断发展和壮大的。甚至还有一些象社区的管理，组件的收集，文档等没列在上面。
因此做一个框架说难，因为的确有太多的东西要考虑，而且涉及到的技术也非常多。但是说易也易，因为有一些象werkzeug的东西可以直接拿过来用。只不过到底要不要做成框架我认为是需要考虑的，正象我前面说的，做框架就是为了复用，复用那些你认为核心的东西：
框架结构， 配置管理， 运行机制等。这些是与人的思维和习惯相关的，是代表框架的特性的东西，可以认为是框架的哲学。如果只是自已用，没必要按框架的方式来做，东西多点少点无所谓。但是框架还是希望要完整一些。当然如果把自已用的东西称为框架也无不可，只不过与我认为框架是给更多人用的想法不同而已。这个看个人想法了。
如果你有了框架的想法不妨根据我的上面列出的内容一个个填个空，然后再与现在有的框架相比较，看一看自已做一个有没有必要。
诚子
1.目录安排,给出一个推荐的方式,比如单独的url,setting文件.但不局限于此,也可以全部放在一个单独的文件里
2.url映射可能会用django的方式,已经习惯了django,但也可能会用个人很喜欢web.py,
3.配置环境由应用来决定.
4.WSGI
5.提供服务器,但不是开发服务器,支持reload
6.应用开发完成可直接部署(基于Tornado的Python Web Server).
7.类似web.py的方式
8.Tornado自带
9.Form处理正在考虑
10.Mako
一些实用的库
Tornado Web Server
Tornado Web Framework
Mako
Elixir
mootools
etc
剩下的
1.框架结构遵循KISS原则
2.配置管理,以约定大于配置的原则
3.tornado的server
4.form正在考虑
其它的
11,session 可能会用web.py的,cache用很简单的libmemcached最多写几个decorator.
12,Elixir,如果不符合需求再进行修改
13,i18n考虑实现
14,无
15,无
16,直接从ORM上写trigger
17,我一直用的mootools会考虑加进去.
18,其它的暂时还没想到
--
my.unix-center.net/~WeiZhicheng
limodou
1. 目录安排你想得比较简单，比如：你的库放在哪里，框架放在哪里，如何安装，模块放在哪里，不过这里有许多与后面的设计相关，比如url是不是象django一样放在单独的文件中，如果不是则不需要考虑。配置文件是只有一个全局的，还是按app分别存放。是不是采用app的组织方式，还是controller的组织方式，这都会引起目录结构的变化。
2. django方式的话那是需要一个urls.py文件了。与web.py的方式很不一样。对后面的运行机制影响很大。
3. 我说的是配置管理，就是采用settings.py还是ini的方式，是只有一个，还是每个app都有（与你的组织有关）。这个也决定了后面你如何设计框架的运行，比如启动时如何读取配置信息。
4. 开发环境我写得只是说到了服务器。象django, uliweb都提供了命令行来辅助创建project,
app。服务器可以运行你的程序。如果不提供开发服务器，那么你的意思就是带一个生产服务器了。
8. 静态文件处理不仅是考虑服务器的处理，还要考虑在模板和view中如何使用它，如何反向生成静态url。
另外你的方案不太象框架，而是象一个具体的配置，特别是数据库。一般的框架是可以运行在不同的服务器上的，而不是依赖于某个server。
从上面的讨论，我感觉你更偏重于web.py，所以我的建议是在web.py上进行封装。不过因为不了解你对web.py的看法所以只是一个建议。web.py也应该是可以部署在tornado上的吧。以前列表里也有人向web.py供献了mako调用的补丁。
limodou
Zoom.Quiet
是也乎，是也乎，
这种经验非常重要的，
应该分享出来
--
http://zoomquiet.org 人生苦短? Pythonic!
向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!]
@@
最后再从应用里独立出来
很多东西你不是实际在做基本考虑不到 就算可以看到现有的一些框架怎么作的 但是也不一定就能理解它为什么会这样作。
诚子
不过到后来觉得,web.py里的东西实在太少了,什么都是要自己写,
而且web.input的方式让我觉得很不爽,都不如django的request来的舒服.
但还是情有独衷,然后就是tornado的出现,也不错,很Simple,很符合我的风格,
其实limodou大哥说得很对,我给的就是一个配置,并不是适合所有人,喜欢就好,
不喜欢的在Python的世界里并不缺少框架,再挑一个.
1.对于url的处理我可能刚才讲的不清楚,程序会有一个main程序,你可以把url写在main里,也可以写在外边从main里import进来.
2.我是比较喜欢django的正则还有发给views参数的方式.
3.setting处理和url是一样的,但原则上只有一个.
4.对,带一个生产服务,也可以用来做开发,之后就可以直接进入生产环境,免去了繁琐的配置服务器的步骤.
8.这个问题也是在考虑,反向生成url确实很酷.
--
my.unix-center.net/~WeiZhicheng
limodou
> 我觉得可以考虑先作应用。
> 最后再从应用里独立出来
> 很多东西你不是实际在做基本考虑不到 就算可以看到现有的一些框架怎么作的 但是也不一定就能理解它为什么会这样作。
>
是啊。象我做框架，并没有想到先要做哪个网站，而是单纯从框架入手，从我理解的框架都有哪些功能，我喜欢哪些，不喜欢哪些，我如何选择，如何构造。等这些都弄好了，才开始是去验证我的想法。象许多东西都是亲手做的或修改过的，比如：
1. 框架结构，自已制定的
2. URL映射机制，copy自werkzeug的一个例子，然后进行了改造
3. 配置管理，自已做的，开发了pyini.py模块
4. 运行机制，自已设计的，参考了django的，支持我设计的app的模式和dispatch功能，和类web2py的无request,response调用方式
5. 开发环境，
6. 部署环境
7. Reqeust, Response的处理，简单封装
8. 静态文件的处理机制 编写了一个wsgi_middle
9. 文件上传及Form提交处理 编写了form模块和文件上传app
10. 模板系统 改自web2py
11. session, cache session是自已重写的，cache估计也快了
12. ORM 自已封装，灵感来自GAE和django
13. i18n 自已做的
14. admin 自已做的
15. 命令行工具 基础为werkzeug，具体的功能是自已写的
16. 扩展设计，复用ulipad的mixin，改造为dispatch
17. 实用工具或模块集，提供uliweb的staticfiles, template, upload, mootools, yaml等app
诚子
是这样的,我就是在使用中对这几种框架感觉很好,所以才有把它们组合到一起的想法,
十一过后先做一个很简单的组合,然后就做一个大一点的项目,再逐渐的完善.
--
my.unix-center.net/~WeiZhicheng
limodou
> 刚开始用web.py的时候,确实被它的简单征服了,感觉这才是真正的用Python写程序.
> 不过到后来觉得,web.py里的东西实在太少了,什么都是要自己写,
> 而且web.input的方式让我觉得很不爽,都不如django的request来的舒服.
> 但还是情有独衷,然后就是tornado的出现,也不错,很Simple,很符合我的风格,
>
> 其实limodou大哥说得很对,我给的就是一个配置,并不是适合所有人,喜欢就好,
> 不喜欢的在Python的世界里并不缺少框架,再挑一个.
>
> 1.对于url的处理我可能刚才讲的不清楚,程序会有一个main程序,你可以把url写在main里,也可以写在外边从main里import进来.
这个可能就是web.py的方式。
> 2.我是比较喜欢django的正则还有发给views参数的方式.
有一些route的库，它们实现是正则，但是是自动转换的，然后发送view的参数和django是一样的。象uliweb就是一个。
> 3.setting处理和url是一样的,但原则上只有一个.
这个就带来一个设计上的问题。不同的框架不同，也是区别框架的地方。
> 4.对,带一个生产服务,也可以用来做开发,之后就可以直接进入生产环境,免去了繁琐的配置服务器的步骤.
但是框架最好不要限定生产服务器，实际部署可以，但是框架最好不要这样。
> 8.这个问题也是在考虑,反向生成url确实很酷.
诚子
林刚
过豆瓣的技术架构发展，开始就是用myisam和InnoDB结合，逐步过渡到memcached和InnoDB结合，其实我觉得memcache和
PostgreSQL会让性能更好的发挥，国内的PostgreSQL关注还是很少
Qiangning Hong
> 1. 要不要组装的判断。你的需求是什么？现有的框架有没有合适的，有没有近似满足的，有没有可以在上面进行扩展的，你有没有时间和能力去维护一个框架。也有些人建议不去使用框架，而是使用工具。那么这也是一种做法。我们做框架的目的就是为了复用，不然直接做一个个的应用就好了。所以做框架比做应用要更多的考虑灵活性，适用性，扩展性等特点。
>
> 2. 如果经过判断的确没有满足条件的框架或方法，那么选取你认为满意的组件开始搭建。
不知道limodou有没有看过pylons，我很好奇你对pylons有哪些地方不满意，因为我觉得uliweb在很多地方和pylons有共通之处。
下面是pylons的解决方案
> 基本功能要考虑：
>
> 1. 框架结构，比如：目录安排，组织方式，是mvc还是mvt，然后组件如何划分，如何管理
mvc和mvt在目前的python框架中区别并不明显。pylons是 model - controller - template 的结构。目录组织形式为：
project
\ app
\ config
\ model
\ controllers
\ templates
\ public (静态文件)
\ lib
\ tests
> 2. URL映射机制，比如：django方式的，还是uliweb方式的，还是web.py方式的，还是web2py方式的
routes 方式，将url映射到一个字典，app再使用这个字典去寻找执行的controller和action。这样比从url直接映射到函数要灵活和方便许多。
> 3. 配置管理，如何管理你的配置信息，使用py源文件，还是ini，还是象uliweb中的pyini，组件的配置如何管理
用 pasterdeploy 管理，为ini格式。
> 4. 运行机制，比如：使用wsgi，还是其它的方式，一个请求如何被处理，如何被应答，与下面的request和response有关
彻底的wsgi，但在编写应用时无须考虑wsgi的细节。
> 5. 开发环境，比如：是否提供开发服务器，是不是支持多线程，是不是可以reload，还是象web2py那样不需要
用 paster 提供的 http server 做开发服务器，有 --reload 参数。通过配置可以使用任意支持wsgi的server。
> 6. 部署环境
任意支持wsgi的环境。
> 7. Reqeust, Response的处理，如何从web server得到一个request, 如何应答一个response
全局可见，thread local的request和response对象，均直接使用webob。
> 8. 静态文件的处理机制
使用paster中的 StaticURLParser wsgi middelware
> 9. 文件上传及Form提交处理
文件上传: webob.Request 直接支持
Form: webhelpers.html.tags 帮助简化form编写，使用formencode进行validate。也可以使用ToscaWdiget。
> 10. 模板系统
默认mako，也可以换用任何buffet支持的模板引擎。
> 有了以上基本内容就包括了：架构设计，开发设计，部署设计。
> 然后你可以选择一些实用的库，比如：
>
> 2. URL映射
> 5. 开发环境
> 6. 部署环境
> 7. Reqeust, Response的处理
> 8. 静态文件的处理机制
> 10. 模板系统
>
> 都可以使用werkzeug完成
用paster也行。
> 当然，上面的象静态文件，模板系统都可以再换成其它的。剩下的象：
>
> 1. 框架结构
> 3. 配置管理
> 4. 运行机制
> 9. 文件上传及Form提交处理
>
> 多半要自已做了，这块是框架的灵魂或核心（9不算）。
paster很成熟了。
formencode也几乎是标准了。
>
> 上面只是基本的框架功能，其它的还有象：
>
> 11. session, cache
beaker
> 12. ORM
sqlalchemy
> 13. i18n
babel
> 14. admin
formalchemy.ext.pylons
> 15. 命令行工具
paster shell
> 16. 扩展设计，如:django的signal, uliweb的dispatch，其它的扩展机制
wsgi middleware
> 17. 实用工具或模块集，比如:django的feed, comment, auth等,uliweb的staticfiles,
> template, upload, mootools, yaml等app
所有的wsgi middleware
> 18. 其它暂时没想到的
>
> 对于上面的功能，并不是框架必须的，但是可能随着框架的完善和成熟，会不断发展和壮大的。甚至还有一些象社区的管理，组件的收集，文档等没列在上面。
>
> 因此做一个框架说难，因为的确有太多的东西要考虑，而且涉及到的技术也非常多。但是说易也易，因为有一些象werkzeug的东西可以直接拿过来用。只不过到底要不要做成框架我认为是需要考虑的，正象我前面说的，做框架就是为了复用，复用那些你认为核心的东西：
> 框架结构， 配置管理， 运行机制等。这些是与人的思维和习惯相关的，是代表框架的特性的东西，可以认为是框架的哲学。如果只是自已用，没必要按框架的方式来做，东西多点少点无所谓。但是框架还是希望要完整一些。当然如果把自已用的东西称为框架也无不可，只不过与我认为框架是给更多人用的想法不同而已。这个看个人想法了。
>
> 如果你有了框架的想法不妨根据我的上面列出的内容一个个填个空，然后再与现在有的框架相比较，看一看自已做一个有没有必要。
我认为pylons的哲学和uliweb的哲学其实很类似，但pylons在使用第三方包和将自己的开发工作以独立包的方式分享上面做的比uliweb更彻底。
我目前觉得pylons唯一的缺点是：许多依赖的包过于依赖setuptools的pkg_resource，但GAE对pkg_resource的支持很有问题，即使Ian
Bicking做了appengine_monkey项目，但在GAE上部署pylons项目还是很困难。
--
Qiangning Hong
limodou
> 2009/9/29 limodou <lim...@gmail.com>:
>> 1. 要不要组装的判断。你的需求是什么？现有的框架有没有合适的，有没有近似满足的，有没有可以在上面进行扩展的，你有没有时间和能力去维护一个框架。也有些人建议不去使用框架，而是使用工具。那么这也是一种做法。我们做框架的目的就是为了复用，不然直接做一个个的应用就好了。所以做框架比做应用要更多的考虑灵活性，适用性，扩展性等特点。
>>
>> 2. 如果经过判断的确没有满足条件的框架或方法，那么选取你认为满意的组件开始搭建。
>
> 不知道limodou有没有看过pylons，我很好奇你对pylons有哪些地方不满意，因为我觉得uliweb在很多地方和pylons有共通之处。
因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。象它用到的一些组件也不是我喜欢的。曾经想用mako，但是感觉还是太复杂。werkzeug它是用了，但是request和response好象是使用的webob，我前段时间是抛弃了webob，全部使用了werkzeug。另外我喜欢django的middle机制，不喜欢完全的wsgi，所以象pylons的配置也不是我喜欢的，复杂。当然可能与我对pylons理解得不深有关。
>
> 下面是pylons的解决方案
>
>> 基本功能要考虑：
>>
>> 1. 框架结构，比如：目录安排，组织方式，是mvc还是mvt，然后组件如何划分，如何管理
>
> mvc和mvt在目前的python框架中区别并不明显。pylons是 model - controller - template 的结构。目录组织形式为：
>
> project
> \ app
> \ config
> \ model
> \ controllers
> \ templates
> \ public (静态文件)
> \ lib
> \ tests
管理方式不同。uliweb是以app方式管理的，而pylons上面看不出app的管理方式来。这一点很重要，也是uliweb中最重要的特征。
>
>> 2. URL映射机制，比如：django方式的，还是uliweb方式的，还是web.py方式的，还是web2py方式的
>
> routes 方式，将url映射到一个字典，app再使用这个字典去寻找执行的controller和action。这样比从url直接映射到函数要灵活和方便许多。
感觉就是麻烦。直接映射的好处就是复用方便。当我使用一个新的app时，简单情况下拿过来就可以用，不用再去修改url的配置，象django,
pylons都多多少少要改些代码，不方便。
>
>> 3. 配置管理，如何管理你的配置信息，使用py源文件，还是ini，还是象uliweb中的pyini，组件的配置如何管理
>
> 用 pasterdeploy 管理，为ini格式。
看过，格式很麻烦，可能是个人口味吧。
>
>> 4. 运行机制，比如：使用wsgi，还是其它的方式，一个请求如何被处理，如何被应答，与下面的request和response有关
>
> 彻底的wsgi，但在编写应用时无须考虑wsgi的细节。
不喜欢彻底的wsgi，这一点许多人有不同的看法。我的看法是wsgi还是太底层，有很多hack的东西。
>
>> 5. 开发环境，比如：是否提供开发服务器，是不是支持多线程，是不是可以reload，还是象web2py那样不需要
>
> 用 paster 提供的 http server 做开发服务器，有 --reload 参数。通过配置可以使用任意支持wsgi的server。
werkzeug已经提供。而且如果pylons也使用的它的话，那是一样的。
>
>> 6. 部署环境
>
> 任意支持wsgi的环境。
这个是一样的。
>
>> 7. Reqeust, Response的处理，如何从web server得到一个request, 如何应答一个response
>
> 全局可见，thread local的request和response对象，均直接使用webob。
webob有问题所以我换掉了。问题就是它使用的是cgi.FieldStorage，在处理以content-lenght的流信息，而不是以\r\n结束的流信息时会挂住。所以webob如果不改是有问题的。
>
>> 8. 静态文件的处理机制
>
> 使用paster中的 StaticURLParser wsgi middelware
这个类似。但是uliweb结合了app的机制可以让static放在任何一个app下。这是连django都没有的功能。
>
>> 9. 文件上传及Form提交处理
>
> 文件上传: webob.Request 直接支持
> Form: webhelpers.html.tags 帮助简化form编写，使用formencode进行validate。也可以使用ToscaWdiget。
>
这个不是最重要的，很多人喜欢手写。uliweb有自已的form库，可以方便地生成不同的form代码，目前可以很好地与yaml相匹配。
>> 10. 模板系统
>
> 默认mako，也可以换用任何buffet支持的模板引擎。
web2py的模板应该是不支持buffet。我喜欢web2py的，所以这块可能的确带有很强的个人色彩。
>
>> 有了以上基本内容就包括了：架构设计，开发设计，部署设计。
>> 然后你可以选择一些实用的库，比如：
>>
>> 2. URL映射
>> 5. 开发环境
>> 6. 部署环境
>> 7. Reqeust, Response的处理
>> 8. 静态文件的处理机制
>> 10. 模板系统
>>
>> 都可以使用werkzeug完成
>
> 用paster也行。
>
>> 当然，上面的象静态文件，模板系统都可以再换成其它的。剩下的象：
>>
>> 1. 框架结构
>> 3. 配置管理
>> 4. 运行机制
>> 9. 文件上传及Form提交处理
>>
>> 多半要自已做了，这块是框架的灵魂或核心（9不算）。
>
> paster很成熟了。
> formencode也几乎是标准了。
>
>>
>> 上面只是基本的框架功能，其它的还有象：
>>
>> 11. session, cache
>
> beaker
为什么我要重写，因为beaker有问题
>
>> 12. ORM
>
> sqlalchemy
一样。uliweb是不绑定ORM的。
>
>> 13. i18n
>
> babel
很难用。
>
>> 14. admin
>
> formalchemy.ext.pylons
和uliweb的不太一样。uliweb的admin目前是构建工具，用于配置信息的设置和app的设置。
>
>> 15. 命令行工具
>
> paster shell
这个每个框架都有自已的。
>
>> 16. 扩展设计，如:django的signal, uliweb的dispatch，其它的扩展机制
>
> wsgi middleware
>
>> 17. 实用工具或模块集，比如:django的feed, comment, auth等,uliweb的staticfiles,
>> template, upload, mootools, yaml等app
>
> 所有的wsgi middleware
>
>> 18. 其它暂时没想到的
>>
>> 对于上面的功能，并不是框架必须的，但是可能随着框架的完善和成熟，会不断发展和壮大的。甚至还有一些象社区的管理，组件的收集，文档等没列在上面。
>>
>> 因此做一个框架说难，因为的确有太多的东西要考虑，而且涉及到的技术也非常多。但是说易也易，因为有一些象werkzeug的东西可以直接拿过来用。只不过到底要不要做成框架我认为是需要考虑的，正象我前面说的，做框架就是为了复用，复用那些你认为核心的东西：
>> 框架结构， 配置管理， 运行机制等。这些是与人的思维和习惯相关的，是代表框架的特性的东西，可以认为是框架的哲学。如果只是自已用，没必要按框架的方式来做，东西多点少点无所谓。但是框架还是希望要完整一些。当然如果把自已用的东西称为框架也无不可，只不过与我认为框架是给更多人用的想法不同而已。这个看个人想法了。
>>
>> 如果你有了框架的想法不妨根据我的上面列出的内容一个个填个空，然后再与现在有的框架相比较，看一看自已做一个有没有必要。
>
> 我认为pylons的哲学和uliweb的哲学其实很类似，但pylons在使用第三方包和将自己的开发工作以独立包的方式分享上面做的比uliweb更彻底。
>
> 我目前觉得pylons唯一的缺点是：许多依赖的包过于依赖setuptools的pkg_resource，但GAE对pkg_resource的支持很有问题，即使Ian
> Bicking做了appengine_monkey项目，但在GAE上部署pylons项目还是很困难。
>
>
从上面可以看出，我认为不一样，最关键的一点就是：app的方式。
在pylons中是constroller，而uliweb中是app，它的单位要大于controller。这个是决定核心的东西，是说明uliweb与pylons最大的设计上的不同。
其它的可能多是一些方便性的考虑，比如：在view中可以不带request,response参数，模板自动映射。这些在pylons中都没有。
还有pylons中使用了一些我认为有问题的模块，象：webob, beaker。
uliweb的哲学是复用，是app的完全化，不是简单地将第三方的包进行集成。
Qiangning Hong
> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
pylons的教程看起来难是因为写教程的人为了强调pylons的灵活性和部署的标准，在教程里加了太多和实现一个wiki无关的东西，比如修改setup.py和setup.cfg啦，上传至pypi啦，美化url啦，使用webhelpers啦。其实真的要做一个wiki
in 15min，也没什么难的。
> 象它用到的一些组件也不是我喜欢的。曾经想用mako，但是感觉还是太复杂。werkzeug它是用了，但是request和response好象是使用的webob，我前段时间是抛弃了webob，全部使用了werkzeug。另外我喜欢django的middle机制，不喜欢完全的wsgi，所以象pylons的配置也不是我喜欢的，复杂。当然可能与我对pylons理解得不深有关。
pylons的组件是全部都可以更换的，包括模板引擎（通过配置）、和request、response系统（通过重载PylonsApp）。
django的middleware机制的问题是只能给django使用，而wsgi middleware是可以给所有wsgi app使用的。可复用性完全不一样。
paste.deploy只是提供了wsgi
app/middleware使用ini配置的一种途径，你也可以直接在代码中写app/middleware配置，正如 pylons 中
app/config/middleware.py 中做的那样。
>> 下面是pylons的解决方案
>>
>>> 基本功能要考虑：
>>>
>>> 1. 框架结构，比如：目录安排，组织方式，是mvc还是mvt，然后组件如何划分，如何管理
>>
>> mvc和mvt在目前的python框架中区别并不明显。pylons是 model - controller - template 的结构。目录组织形式为：
>>
>> project
>> \ app
>> \ config
>> \ model
>> \ controllers
>> \ templates
>> \ public (静态文件)
>> \ lib
>> \ tests
>
> 管理方式不同。uliweb是以app方式管理的，而pylons上面看不出app的管理方式来。这一点很重要，也是uliweb中最重要的特征。
pylons的project目录下是可以有多个app的，每个都是一个python package。像这样：
project
\ app1
\ app2
每个app管理自己的model, controllers, template, static files, etc.
在 project/development.ini 中可以用paste.deploy的方式指定 [composite:main] 来将不同的
app 挂载到不同的 url 下，当然你也可以让主app的routes来做这个app dispatch的事情。
>>> 2. URL映射机制，比如：django方式的，还是uliweb方式的，还是web.py方式的，还是web2py方式的
>>
>> routes 方式，将url映射到一个字典，app再使用这个字典去寻找执行的controller和action。这样比从url直接映射到函数要灵活和方便许多。
>
> 感觉就是麻烦。直接映射的好处就是复用方便。当我使用一个新的app时，简单情况下拿过来就可以用，不用再去修改url的配置，象django,
> pylons都多多少少要改些代码，不方便。
pylons也不需要改url的配置。
>>> 3. 配置管理，如何管理你的配置信息，使用py源文件，还是ini，还是象uliweb中的pyini，组件的配置如何管理
>>
>> 用 pasterdeploy 管理，为ini格式。
>
> 看过，格式很麻烦，可能是个人口味吧。
在平时的实际使用中，几乎不需要操心这个ini文件。而且你仔细看一下那个development.ini，其实很简单易懂。而且pylons会把logging的配置也用这个ini管理起来，在调试时方便很多。
>>> 4. 运行机制，比如：使用wsgi，还是其它的方式，一个请求如何被处理，如何被应答，与下面的request和response有关
>>
>> 彻底的wsgi，但在编写应用时无须考虑wsgi的细节。
>
> 不喜欢彻底的wsgi，这一点许多人有不同的看法。我的看法是wsgi还是太底层，有很多hack的东西。
在使用pylons的过程中几乎不需要操心wsgi，routes和webob基本上已经把所有wsgi的细节都隐藏起来了。只有在写middleware时才会和environ,
start_response这样的名字打交道，而且及时是写middleware，基本上也就是拿environ当个存取内容的大dict使而已，不会涉及什么底层的东西。
再者说，wsgi本身就没有什么复杂的东西。会python就能会wsgi。
>>> 7. Reqeust, Response的处理，如何从web server得到一个request, 如何应答一个response
>>
>> 全局可见，thread local的request和response对象，均直接使用webob。
>
> webob有问题所以我换掉了。问题就是它使用的是cgi.FieldStorage，在处理以content-lenght的流信息，而不是以\r\n结束的流信息时会挂住。所以webob如果不改是有问题的。
limodou你能给一个复现问题的用例吗？如果能够到 bugs.python.org 去提交一个 bug report 就更好了，毕竟
cgi 是标准库里的东西，这个东东的质量对整个python社区都很有影响。
>>> 8. 静态文件的处理机制
>>
>> 使用paster中的 StaticURLParser wsgi middelware
>
> 这个类似。但是uliweb结合了app的机制可以让static放在任何一个app下。这是连django都没有的功能。
pylons也是把static files放在app下单独管理的，托wsgi的福。
>>> 9. 文件上传及Form提交处理
>>
>> 文件上传: webob.Request 直接支持
>> Form: webhelpers.html.tags 帮助简化form编写，使用formencode进行validate。也可以使用ToscaWdiget。
>
> 这个不是最重要的，很多人喜欢手写。uliweb有自已的form库，可以方便地生成不同的form代码，目前可以很好地与yaml相匹配。
当然，我用pylons多数情况也是手写form。
form库的问题，推荐看看Ian Bicking的
http://blog.ianbicking.org/on-form-libraries.html 。form
generation本身不是一个重要的事情，因为不存在最优解，倒是把解决form
generation时发明的轮子们独立贡献出来，使得其他人可以自由应用，这一点更重要。
至于form validation，formencode已经做的很好了。
>>> 10. 模板系统
>>
>> 默认mako，也可以换用任何buffet支持的模板引擎。
>
> web2py的模板应该是不支持buffet。我喜欢web2py的，所以这块可能的确带有很强的个人色彩。
buffet只是在模板引擎外加了一个很轻的封装，提供一致的接口而已。对一个新模板引擎做buffet支持应该很简单。然后只要在
setup.py 里说明实现了 python.templating.engines 这个 entry point
就可以直接在pylons里用了。
>> beaker
>
> 为什么我要重写，因为beaker有问题
你说的beaker的问题是这个吗？
http://hi.baidu.com/limodou/blog/item/1ab2b17edc3ab4310dd7da01.html
不知道你有没有和作者交流过这个问题。另外，你重写的session manager能作为wsgi
middleware发布出来吗？这样其他社区也可以使用你的工作成果了。
>>> 13. i18n
>>
>> babel
>
> 很难用。
难用指的是？
>>> 14. admin
>>
>> formalchemy.ext.pylons
>
> 和uliweb的不太一样。uliweb的admin目前是构建工具，用于配置信息的设置和app的设置。
哦，我以为你说的是django那个admin界面。
设置这种事情还是用配置文件最简单，需要使用工具来做吗？
>>> 15. 命令行工具
>>
>> paster shell
>
> 这个每个框架都有自已的。
对，但是使用paste.script构建shell工具，可以省掉当前环境判断、配置文件加载管理等一系列麻烦，shell工具只需要专注于shell本身的事情就行了。
> 从上面可以看出，我认为不一样，最关键的一点就是：app的方式。
> 在pylons中是constroller，而uliweb中是app，它的单位要大于controller。这个是决定核心的东西，是说明uliweb与pylons最大的设计上的不同。
pylons中和django的app对应的东西并不是controllers（controller对应的是django的view），而就是app本身这个python
package。所以pylons的app是可以直接做成一个egg放到pypi上去的。
> 其它的可能多是一些方便性的考虑，比如：在view中可以不带request,response参数，模板自动映射。这些在pylons中都没有。
在view中可以不带request,response参数，模板自动映射
这两个是指？
> 还有pylons中使用了一些我认为有问题的模块，象：webob, beaker。
> uliweb的哲学是复用，是app的完全化，不是简单地将第三方的包进行集成。
--
Qiangning Hong
http://www.douban.com/people/hongqn/
Leo Jay
> 2009/9/29 limodou <lim...@gmail.com>:
>> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>
> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
>
> pylons的教程看起来难是因为写教程的人为了强调pylons的灵活性和部署的标准，在教程里加了太多和实现一个wiki无关的东西，比如修改setup.py和setup.cfg啦，上传至pypi啦，美化url啦，使用webhelpers啦。其实真的要做一个wiki
> in 15min，也没什么难的。
>
pylons其实很符合我的胃口，就是有一点让我很郁闷，为什么不提供一个下载包呢？
--
Best Regards,
Leo Jay
leopay
> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具
我感觉pylons的哲学更开放些，个人也比较欣赏这种胶水
limodou
> 2009/9/29 limodou <lim...@gmail.com>:
>> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>
> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
>
都感冒，好象除了pylons别人很少用。我是基本上没用过。这些功能我认为werkzeug基本上可以包括了。感觉werkzeug更好一些。
> pylons的教程看起来难是因为写教程的人为了强调pylons的灵活性和部署的标准，在教程里加了太多和实现一个wiki无关的东西，比如修改setup.py和setup.cfg啦，上传至pypi啦，美化url啦，使用webhelpers啦。其实真的要做一个wiki
> in 15min，也没什么难的。
也许吧。但是给我的感觉就是很麻烦。不知道谁可以写一个很简单的hello, world程序看看。
>
>> 象它用到的一些组件也不是我喜欢的。曾经想用mako，但是感觉还是太复杂。werkzeug它是用了，但是request和response好象是使用的webob，我前段时间是抛弃了webob，全部使用了werkzeug。另外我喜欢django的middle机制，不喜欢完全的wsgi，所以象pylons的配置也不是我喜欢的，复杂。当然可能与我对pylons理解得不深有关。
>
> pylons的组件是全部都可以更换的，包括模板引擎（通过配置）、和request、response系统（通过重载PylonsApp）。
>
那和我重写也差不多了。
> django的middleware机制的问题是只能给django使用，而wsgi middleware是可以给所有wsgi app使用的。可复用性完全不一样。
>
所以wsgi级别的我并不喜欢。wsgi还是太底层，并且以env作为数据传输的接口，在env中放置对象，我不认为是好的做法。
> paste.deploy只是提供了wsgi
> app/middleware使用ini配置的一种途径，你也可以直接在代码中写app/middleware配置，正如 pylons 中
> app/config/middleware.py 中做的那样。
>
>>> 下面是pylons的解决方案
>>>
>>>> 基本功能要考虑：
>>>>
>>>> 1. 框架结构，比如：目录安排，组织方式，是mvc还是mvt，然后组件如何划分，如何管理
>>>
>>> mvc和mvt在目前的python框架中区别并不明显。pylons是 model - controller - template 的结构。目录组织形式为：
>>>
>>> project
>>> \ app
>>> \ config
>>> \ model
>>> \ controllers
>>> \ templates
>>> \ public (静态文件)
>>> \ lib
>>> \ tests
>>
>> 管理方式不同。uliweb是以app方式管理的，而pylons上面看不出app的管理方式来。这一点很重要，也是uliweb中最重要的特征。
>
> pylons的project目录下是可以有多个app的，每个都是一个python package。像这样：
>
> project
> \ app1
> \ app2
>
> 每个app管理自己的model, controllers, template, static files, etc.
>
> 在 project/development.ini 中可以用paste.deploy的方式指定 [composite:main] 来将不同的
> app 挂载到不同的 url 下，当然你也可以让主app的routes来做这个app dispatch的事情。
还是不清楚。在uliweb中app是组织单位，但是使用时可以看成是一个整体，并且app中的东西可以没有model，view之类的东西。pylons的app是不是一个wsgi的application？这个就和web2py很象，相当于一个运行单位。和uliweb的app不是一个概念。并且url的挂接是对app下的所有url都起作用还是什么的？比如在某个app中定义了/static，在另一个也定义了/static，那么会不会有冲突？感觉不是一个概念，uliweb的是和django接近。
>
>>>> 2. URL映射机制，比如：django方式的，还是uliweb方式的，还是web.py方式的，还是web2py方式的
>>>
>>> routes 方式，将url映射到一个字典，app再使用这个字典去寻找执行的controller和action。这样比从url直接映射到函数要灵活和方便许多。
>>
>> 感觉就是麻烦。直接映射的好处就是复用方便。当我使用一个新的app时，简单情况下拿过来就可以用，不用再去修改url的配置，象django,
>> pylons都多多少少要改些代码，不方便。
>
> pylons也不需要改url的配置。
这个和前面的问题有关。如果是运行单位有可能不需要，但是会不会有url的冲突问题。我想这个问题是和运行环境有关。pylons可以看成一个运行的容器，因此当不同的app运行时是独立的，所以不需要修改。而django是开发级别的app，uliweb也是。
如果是这样的不同，那是根本性的差别了。
>
>>>> 3. 配置管理，如何管理你的配置信息，使用py源文件，还是ini，还是象uliweb中的pyini，组件的配置如何管理
>>>
>>> 用 pasterdeploy 管理，为ini格式。
>>
>> 看过，格式很麻烦，可能是个人口味吧。
>
> 在平时的实际使用中，几乎不需要操心这个ini文件。而且你仔细看一下那个development.ini，其实很简单易懂。而且pylons会把logging的配置也用这个ini管理起来，在调试时方便很多。
>
>>>> 4. 运行机制，比如：使用wsgi，还是其它的方式，一个请求如何被处理，如何被应答，与下面的request和response有关
>>>
>>> 彻底的wsgi，但在编写应用时无须考虑wsgi的细节。
>>
>> 不喜欢彻底的wsgi，这一点许多人有不同的看法。我的看法是wsgi还是太底层，有很多hack的东西。
>
> 在使用pylons的过程中几乎不需要操心wsgi，routes和webob基本上已经把所有wsgi的细节都隐藏起来了。只有在写middleware时才会和environ,
> start_response这样的名字打交道，而且及时是写middleware，基本上也就是拿environ当个存取内容的大dict使而已，不会涉及什么底层的东西。
>
> 再者说，wsgi本身就没有什么复杂的东西。会python就能会wsgi。
>
>>>> 7. Reqeust, Response的处理，如何从web server得到一个request, 如何应答一个response
>>>
>>> 全局可见，thread local的request和response对象，均直接使用webob。
>>
>> webob有问题所以我换掉了。问题就是它使用的是cgi.FieldStorage，在处理以content-lenght的流信息，而不是以\r\n结束的流信息时会挂住。所以webob如果不改是有问题的。
>
> limodou你能给一个复现问题的用例吗？如果能够到 bugs.python.org 去提交一个 bug report 就更好了，毕竟
> cgi 是标准库里的东西，这个东东的质量对整个python社区都很有影响。
>
当上传文件时，我就是在使用fancyupload时发现的，它是一个flash的上传组件。它结束时并没有回车换行。而webob使用了cig.FieldStorage，它是使用readline()来处理的，结果收不到最后的\r\n'结果会挂起，就是这个问题。而werkzeug在他的blog中写了相关的内容。
>>>> 8. 静态文件的处理机制
>>>
>>> 使用paster中的 StaticURLParser wsgi middelware
>>
>> 这个类似。但是uliweb结合了app的机制可以让static放在任何一个app下。这是连django都没有的功能。
>
> pylons也是把static files放在app下单独管理的，托wsgi的福。
>
还是和app的模式有关。
>>>> 9. 文件上传及Form提交处理
>>>
>>> 文件上传: webob.Request 直接支持
>>> Form: webhelpers.html.tags 帮助简化form编写，使用formencode进行validate。也可以使用ToscaWdiget。
>>
>> 这个不是最重要的，很多人喜欢手写。uliweb有自已的form库，可以方便地生成不同的form代码，目前可以很好地与yaml相匹配。
>
> 当然，我用pylons多数情况也是手写form。
>
> form库的问题，推荐看看Ian Bicking的
> http://blog.ianbicking.org/on-form-libraries.html 。form
> generation本身不是一个重要的事情，因为不存在最优解，倒是把解决form
> generation时发明的轮子们独立贡献出来，使得其他人可以自由应用，这一点更重要。
>
> 至于form validation，formencode已经做的很好了。
>
uliweb也是开源的。我是更喜欢django方式的form类。
>>>> 10. 模板系统
>>>
>>> 默认mako，也可以换用任何buffet支持的模板引擎。
>>
>> web2py的模板应该是不支持buffet。我喜欢web2py的，所以这块可能的确带有很强的个人色彩。
>
> buffet只是在模板引擎外加了一个很轻的封装，提供一致的接口而已。对一个新模板引擎做buffet支持应该很简单。然后只要在
> setup.py 里说明实现了 python.templating.engines 这个 entry point
> 就可以直接在pylons里用了。
>
>>> beaker
>>
>> 为什么我要重写，因为beaker有问题
>
> 你说的beaker的问题是这个吗？
> http://hi.baidu.com/limodou/blog/item/1ab2b17edc3ab4310dd7da01.html
>
> 不知道你有没有和作者交流过这个问题。另外，你重写的session manager能作为wsgi
> middleware发布出来吗？这样其他社区也可以使用你的工作成果了。
>
交流过 http://bitbucket.org/bbangert/beaker/issue/16/how-to-stop-session-to-create-session-file
还没有被解决。并且不支持rememberme的功能。我的sessionmanager写的是符合uliweb的middleware的东西，但是session库本身是独立的，在uliweb/lib/weto中，可以随便使用。
>>>> 13. i18n
>>>
>>> babel
>>
>> 很难用。
>
> 难用指的是？
>
曾经想用，但是文档示例基本没看懂，所以自已做了一个。
>>>> 14. admin
>>>
>>> formalchemy.ext.pylons
>>
>> 和uliweb的不太一样。uliweb的admin目前是构建工具，用于配置信息的设置和app的设置。
>
> 哦，我以为你说的是django那个admin界面。
> 设置这种事情还是用配置文件最简单，需要使用工具来做吗？
DRY
>
>>>> 15. 命令行工具
>>>
>>> paster shell
>>
>> 这个每个框架都有自已的。
>
> 对，但是使用paste.script构建shell工具，可以省掉当前环境判断、配置文件加载管理等一系列麻烦，shell工具只需要专注于shell本身的事情就行了。
>
>> 从上面可以看出，我认为不一样，最关键的一点就是：app的方式。
>> 在pylons中是constroller，而uliweb中是app，它的单位要大于controller。这个是决定核心的东西，是说明uliweb与pylons最大的设计上的不同。
>
> pylons中和django的app对应的东西并不是controllers（controller对应的是django的view），而就是app本身这个python
> package。所以pylons的app是可以直接做成一个egg放到pypi上去的。
>
关键是它是不是开发的最小单位，还是运行的最小单位。
>> 其它的可能多是一些方便性的考虑，比如：在view中可以不带request,response参数，模板自动映射。这些在pylons中都没有。
>
> 在view中可以不带request,response参数，模板自动映射
> 这两个是指？
比如定义一个view函数，可以：
def index():
return {}
没有传入request，但是却可以直接在index中使用如果一个view返回dict则框架会自动查找与view函数同名的模板文件进行处理。而不用手工去指定了。
>
>> 还有pylons中使用了一些我认为有问题的模块，象：webob, beaker。
>> uliweb的哲学是复用，是app的完全化，不是简单地将第三方的包进行集成。
>
其实还是有许多的选择和设计不同的。
limodou
> 2009/9/29 Qiangning Hong <hon...@gmail.com>
>>
>> 2009/9/29 limodou <lim...@gmail.com>:
>> > 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> > 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>>
>> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具
>
> 我感觉pylons的哲学更开放些，个人也比较欣赏这种胶水
>
能开源发布的框架可以认为都是开放的，你认为的更开放体现在什么地方？
是框架，还是团队
诚子
--
my.unix-center.net/~WeiZhicheng
leopay
2009/9/29 leopay <leo...@gmail.com>:
> 2009/9/29 Qiangning Hong <hon...@gmail.com>能开源发布的框架可以认为都是开放的，你认为的更开放体现在什么地方？
>>
>> 2009/9/29 limodou <lim...@gmail.com>:
>> > 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> > 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>>
>> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具
>
> 我感觉pylons的哲学更开放些，个人也比较欣赏这种胶水
>
是框架，还是团队
leopay
2009/9/29 Qiangning Hong <hon...@gmail.com>:都感冒，好象除了pylons别人很少用。我是基本上没用过。
> 2009/9/29 limodou <lim...@gmail.com>:
>> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>
> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
>
limodou
> 他所指的开放可能指的是模块上的,PyIons组合起来更容易,django就很难.
>
这个我认为不是很严重，主要还是设计上的一些理念。
诚子
limodou
>
>
> 2009/9/29 limodou <lim...@gmail.com>
>>
>> 2009/9/29 leopay <leo...@gmail.com>:
>> > 2009/9/29 Qiangning Hong <hon...@gmail.com>
>> >>
>> >> 2009/9/29 limodou <lim...@gmail.com>:
>> >> > 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> >> > 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>> >>
>> >> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具
>> >
>> > 我感觉pylons的哲学更开放些，个人也比较欣赏这种胶水
>> >
>>
>> 能开源发布的框架可以认为都是开放的，你认为的更开放体现在什么地方？
>>
>> 是框架，还是团队
>
> 如Qiangning Hong提到的
> django的middleware机制的问题是只能给django使用，而pylons的wsgi middleware是可以给所有wsgi app使用的
>
对wsgi的不同看法： http://www.b-list.org/weblog/2009/aug/10/wsgi/
完全通用其实很难。wsgi并不是最好的选择。
ubunoon
limodou
ubunoon
limodou
>
>
> 2009/9/29 limodou <lim...@gmail.com>
>>
>> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> > 2009/9/29 limodou <lim...@gmail.com>:
>> >> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>> >> 因为我一直对paster很感冒，所以一直没有动力去学pylons。特别是它的教程，一直感觉比起django难很多。
>> >
>> >
>> > paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
>> >
>>
>> 都感冒，好象除了pylons别人很少用。我是基本上没用过。
>
> repoze.bfg用到paste的
真是不好意思，repoze我也没用过啊。repoze我也看了一点，感觉还是不简单。和pylons差不多，为什么它们不合呢？
limodou
> 少些了一句：
> uliweb感觉相对更加符合小程序员的开发，简单规模的网站，大规模的网站应用感觉不怎么适合
大规模的应该是什么样？象quixote基本上只处理了模板，request和response的都可以用在豆瓣上，django都可以用在好看簿上，为什么uliweb不合适了？从设计上uliweb并没有问题，缺的只是成熟度。
limodou
> limodou想要一个pylons的hello
> world，其实在创建pylons的controller时候，就已经自动为你配置了一个url以及一个输出hello world的字符串。开启paster
> serve --reload development.ini就可以访问了。
> pylons和uliweb我都看过一些，pylons是一个比较庞大的体系，更适合构架公司级大规模的网站应用，需要花费较多的时间去学习pylons直接模块的关系。
> uliweb感觉相对更加符合小程序员的开发，简单规模的网站，大规模的网站应用。
> 学习uliweb的曲线是比较平滑的，学习pylons的曲线是比较抖的，我以为层次面不同。
>
uliweb现在没有大规模的应用，还有待于成熟。所以现在就说适合不适合要看真正做出来怎么样。其实uliweb主要是在于一个设计，用的也是别人的东西，只是设计不同，所以还很难说。而学习曲线平滑（当然我也希望）如果是真的，正好说明uliweb的优势，不是吗？
功能上既然很接近，那么uliweb的缺陷在哪里呢？只是成熟度不够吗？（其实我是知道我还有许多的工作要做，不过别人不感兴趣，也不足为外人道也）
Qiangning Hong
> 都感冒，好象除了pylons别人很少用。我是基本上没用过。这些功能我认为werkzeug基本上可以包括了。感觉werkzeug更好一些。
http://files.getdropbox.com/u/87045/x/pypi-dependency.txt
这个文件（要翻墙）统计了pypi上项目的dependence，grep
了一下，有119个项目是显式指定依赖Paste的，这还不包括那些次级依赖的，和没有上传到pypi上的。
基本上Paste是wsgi的鼻祖了，最初期的一些wsgi包基本上都是这个里头的。而且Paste在开发过程中还会把一些独立性和可重用比较强的组件分离出来单独发布，比如WebOb，这个基本上都成标准组件了。
>> pylons的教程看起来难是因为写教程的人为了强调pylons的灵活性和部署的标准，在教程里加了太多和实现一个wiki无关的东西，比如修改setup.py和setup.cfg啦，上传至pypi啦，美化url啦，使用webhelpers啦。其实真的要做一个wiki
>> in 15min，也没什么难的。
>
> 也许吧。但是给我的感觉就是很麻烦。不知道谁可以写一个很简单的hello, world程序看看。
只要hello world的话非常简单，一行代码都不用，四条命令搞定：
$ paster create -t pylons HelloWorld
$ cd HelloWorld
$ paster controller hello
$ paster serve --reload development.ini
访问 http://localhost:5000/hello/index 就可以看到一行 Hello World.
>>> 象它用到的一些组件也不是我喜欢的。曾经想用mako，但是感觉还是太复杂。werkzeug它是用了，但是request和response好象是使用的webob，我前段时间是抛弃了webob，全部使用了werkzeug。另外我喜欢django的middle机制，不喜欢完全的wsgi，所以象pylons的配置也不是我喜欢的，复杂。当然可能与我对pylons理解得不深有关。
>>
>> pylons的组件是全部都可以更换的，包括模板引擎（通过配置）、和request、response系统（通过重载PylonsApp）。
>>
>
> 那和我重写也差不多了。
但是只需要重写相关的部分，其他的部分还可以继续用。这个就类似TurboGears2的做法，把不喜欢的换掉，但底层架子还是Pylons的。这样不用每个web
framework都重头实现所有的东西了。
>> django的middleware机制的问题是只能给django使用，而wsgi middleware是可以给所有wsgi app使用的。可复用性完全不一样。
> 所以wsgi级别的我并不喜欢。wsgi还是太底层，并且以env作为数据传输的接口，在env中放置对象，我不认为是好的做法。
这个见仁见智。我倒是认为wsgi用一个dict作为环境，在不同组件之间传输信息的做法，非常的简洁，至少比把什么都放到request对象里要强。
而且既然WSGI已经是Python官方的标准(PEP-333)，是被各种框架支持最好的协议，如果想让自己的代码达到尽可能大的可重用性的话，为什么不支持它呢？
以前在WSGI社区看到一个说法：django middleware considered
harmful。就是说由于django自己搞了一套middleware机制，使得大量的middleware需要开发两份，一份给django用，一份是wsgi的。如果django
middleware能够遵从wsgi标准的话，社区的力量就可以更集中了。
>> pylons的project目录下是可以有多个app的，每个都是一个python package。像这样：
>>
>> project
>> \ app1
>> \ app2
>>
>> 每个app管理自己的model, controllers, template, static files, etc.
>>
>> 在 project/development.ini 中可以用paste.deploy的方式指定 [composite:main] 来将不同的
>> app 挂载到不同的 url 下，当然你也可以让主app的routes来做这个app dispatch的事情。
>
> 还是不清楚。在uliweb中app是组织单位，但是使用时可以看成是一个整体，并且app中的东西可以没有model，view之类的东西。pylons的app是不是一个wsgi的application？这个就和web2py很象，相当于一个运行单位。和uliweb的app不是一个概念。并且url的挂接是对app下的所有url都起作用还是什么的？比如在某个app中定义了/static，在另一个也定义了/static，那么会不会有冲突？感觉不是一个概念，uliweb的是和django接近。
pylons的app是一个wsgi app。其实只要是wsgi app就可以，不一定要有model, view这些东西。
有什么页面介绍uliweb中的app吗？组织单位这个概念和建立python
package名字空间有什么区别呢？我理解的django的app也是有独自的model和view的，他们只是共享一个项目配置和url配置而已。而pylons下的app是自己包含这些东西的，在项目级别只是决定如何挂载各app而已。uliweb的核心应该就是app重用，如果有个详细的介绍会比较好一些。
app的挂载一般是通过url前缀来实现，比如把 wiki app 挂在 /wiki 下，poller app 挂在 /poll
下。static file是自己控制的，比如 /wiki/js/ , /poll/js/
。如果要想实现所有的静态文件都整合后放在一个目录下，用 paste.cascade.Cascade 这个 wsgi middleware
配置一下优先顺序，然后挂载根下就好了。不知道uliweb想要实现的是什么样的功能。
>> limodou你能给一个复现问题的用例吗？如果能够到 bugs.python.org 去提交一个 bug report 就更好了，毕竟
>> cgi 是标准库里的东西，这个东东的质量对整个python社区都很有影响。
>
> 当上传文件时，我就是在使用fancyupload时发现的，它是一个flash的上传组件。它结束时并没有回车换行。而webob使用了cig.FieldStorage，它是使用readline()来处理的，结果收不到最后的\r\n'结果会挂起，就是这个问题。而werkzeug在他的blog中写了相关的内容。
抱歉没有google到那篇blog，能给个地址吗？
>> 你说的beaker的问题是这个吗？
>> http://hi.baidu.com/limodou/blog/item/1ab2b17edc3ab4310dd7da01.html
>>
>> 不知道你有没有和作者交流过这个问题。另外，你重写的session manager能作为wsgi
>> middleware发布出来吗？这样其他社区也可以使用你的工作成果了。
>
> 交流过 http://bitbucket.org/bbangert/beaker/issue/16/how-to-stop-session-to-create-session-file
> 还没有被解决。并且不支持rememberme的功能。我的sessionmanager写的是符合uliweb的middleware的东西，但是session库本身是独立的，在uliweb/lib/weto中，可以随便使用。
看了一下这个issue，感觉上你是希望在request没有操作session的情况下，不要执行session.persist()。我看了一下pylons，pylons是直接使用beaker提供的wsgi
middleware: beaker.middleware.SessionMiddleware
，在这个middleware的__call__()方法可以看到，在start_response时，有一段判断：
if session.dirty() or (session.accessed() and
self.options.get('auto')):
session.persist()
因此，其实直接用 beaker 提供的 middleware 应该就不会有你的困扰。如果你不用他的middleware要自己写的话，用同样的逻辑就可以。
不知道我是否正确理解了你的问题。
>> 哦，我以为你说的是django那个admin界面。
>> 设置这种事情还是用配置文件最简单，需要使用工具来做吗？
>
> DRY
用配置文件不DRY吗？
>> 在view中可以不带request,response参数，模板自动映射
>> 这两个是指？
>
> 比如定义一个view函数，可以：
>
> def index():
> return {}
>
> 没有传入request，但是却可以直接在index中使用
pylons也是这样的啊，在模块顶部 from pylons import request 就行了，不需要把 request 传入函数。那是django的做法。
> 如果一个view返回dict则框架会自动查找与view函数同名的模板文件进行处理。而不用手工去指定了。
这个在lib/base.py重载一下 WSGIController._dispatch_call() 就 ok 了：
class BaseController(WSGIController):
def _dispatch_call(self):
response = WSGIController._dispatch_call(self)
if isinstance(response, dict):
response =
render('/'+request.environ['pylons.routes_dict']['action']+'.mako',
response)
return response
这样所有的action就都支持这个功能了。
> 其实还是有许多的选择和设计不同的。
没错，不同的选择会导致不同的设计。我自己也会没事写框架玩，这个很正常。
我回复这个thread其实是想说：做框架不如做库，做只能给一个框架用的库不如做wsgi库。werkzeug就是一个很好的例子，他把自己开发过程中做的工作，基本上都用wsgi的方式单独发布出来了，他自己本身并不是一个框架，而是一堆轮子，和Paste类似。所以在其他的项目中，包括Pylons，使用他的东西就几乎没有任何障碍，对整个社区都是有好处的。
Qiangning Hong
看那篇文章一定要把下面的回复看完，文章里很多对wsgi的指责其实是作者自己没有理解。
wsgi并不完美，但它是目前最好的选择。
--
Qiangning Hong
Qiangning Hong
> limodou想要一个pylons的hello
> world，其实在创建pylons的controller时候，就已经自动为你配置了一个url以及一个输出hello world的字符串。开启paster
> serve --reload development.ini就可以访问了。
> pylons和uliweb我都看过一些，pylons是一个比较庞大的体系，更适合构架公司级大规模的网站应用，需要花费较多的时间去学习pylons直接模块的关系。
> uliweb感觉相对更加符合小程序员的开发，简单规模的网站，大规模的网站应用。
> 学习uliweb的曲线是比较平滑的，学习pylons的曲线是比较抖的，我以为层次面不同。
pylons的学习曲线抖吗？我们最近一个新项目使用pylons开发，开发人员前一天晚上开始看pylons，第二天项目主体框架基本就出来了。上手要弄明白的无非就是url映射到哪个函数去执行了，由于pylons默认设置了
'/{controller}/{action}' 这个route，所以连这个都不用理解就可以开始写代码了。
要想把一个框架用通透，那些高级特性肯定都是要花时间去琢磨的，这个哪个框架都一样。
pylons的文档不好倒是真的。
--
Qiangning Hong
Qiangning Hong
> 真是不好意思，repoze我也没用过啊。repoze我也看了一点，感觉还是不简单。和pylons差不多，为什么它们不合呢？
因为 repoze 存在的意义是要证明 zope 也可以做主流web应用啊。
由于 repoze 也是基于 wsgi 的，他的开发成果也可以直接应用在 pylons 中。比如最近pylons社区经常推荐使用
repoze.who 和 repoze.what 来做身份验证系统，而不推荐用原来的 AuthKit 了。
--
Qiangning Hong
Qiangning Hong
> 2009/9/29 ubunoon <net...@gmail.com>:
>> 少些了一句：
>> uliweb感觉相对更加符合小程序员的开发，简单规模的网站，大规模的网站应用感觉不怎么适合
>
> 大规模的应该是什么样？象quixote基本上只处理了模板，request和response的都可以用在豆瓣上，django都可以用在好看簿上，为什么uliweb不合适了？从设计上uliweb并没有问题，缺的只是成熟度。
其实越大规模的网站对框架的要求越低，因为肯定很多部分是需要自己定制的。框架只要能够解决快速开发的问题，等到规模大后能够很方便的把组件替换，这样就够了。
--
Qiangning Hong
ubunoon
Qiangning Hong
> pylons的文档我倒是有一份，就是pylons官网上说的那本书，可惜英文的看着头疼。
> 开发人员前一天看pylons，第二天主体框架就出来了，涉及到细节了么？就好比用MFC，直接用类向导帮你生成一大片代码，然后你可以运行了，但是，不理解里面的内容，可以说知道pylons了吗？
我没说知道pylons，说的是上手。反正包含了十个左右页面，两三张数据表和对应的model
class，form处理，身份验证，cookie处理，js, css。有这些东西就可以开始开发了吧。剩下的东西边做边学就行了。
要理解“里面”的内容，一个晚上显然不够。你说uliweb学习曲线平滑，orm、i18n、扩展系统哪样不需要花时间深入？pylons也是一样的。
判断一样东西的学习曲线是否平滑，只需要看进入到可以使用它工作的状态有多高的代价就行了。用MFC写界面的学习曲线显然比用win32
api手写C代码的学习曲线平滑的多。pylons的学习曲线我觉得和django相当，但考虑到它的tutorial文档写的比django的差，就算比django陡一点点好了。
--
Qiangning Hong
limodou
> 2009/9/29 limodou <lim...@gmail.com>:
>> 2009/9/29 Qiangning Hong <hon...@gmail.com>:
>>> paster分三个部分，一个wsgi组件库(paste)，一个部署配置库(paster.deploy)和一个命令行工具(paster.script)，你是对哪一部分感冒？
>> 都感冒，好象除了pylons别人很少用。我是基本上没用过。这些功能我认为werkzeug基本上可以包括了。感觉werkzeug更好一些。
>
> http://files.getdropbox.com/u/87045/x/pypi-dependency.txt
> 这个文件（要翻墙）统计了pypi上项目的dependence，grep
> 了一下，有119个项目是显式指定依赖Paste的，这还不包括那些次级依赖的，和没有上传到pypi上的。
>
> 基本上Paste是wsgi的鼻祖了，最初期的一些wsgi包基本上都是这个里头的。而且Paste在开发过程中还会把一些独立性和可重用比较强的组件分离出来单独发布，比如WebOb，这个基本上都成标准组件了。
>
要声明uliweb是wsgi支持的，而且uliweb的静态文件服务也是使用wsgi实现的。只不过uliewb内部的app是不需要wsgi实现的。而且就wsgi更适合在request，
response处理中插入一些功能，请处理处理时用不用并不很重要。
>>> pylons的教程看起来难是因为写教程的人为了强调pylons的灵活性和部署的标准，在教程里加了太多和实现一个wiki无关的东西，比如修改setup.py和setup.cfg啦，上传至pypi啦，美化url啦，使用webhelpers啦。其实真的要做一个wiki
>>> in 15min，也没什么难的。
>>
>> 也许吧。但是给我的感觉就是很麻烦。不知道谁可以写一个很简单的hello, world程序看看。
>
>
> 只要hello world的话非常简单，一行代码都不用，四条命令搞定：
>
> $ paster create -t pylons HelloWorld
> $ cd HelloWorld
> $ paster controller hello
> $ paster serve --reload development.ini
>
> 访问 http://localhost:5000/hello/index 就可以看到一行 Hello World.
这个和uliweb一样。
>
>>>> 象它用到的一些组件也不是我喜欢的。曾经想用mako，但是感觉还是太复杂。werkzeug它是用了，但是request和response好象是使用的webob，我前段时间是抛弃了webob，全部使用了werkzeug。另外我喜欢django的middle机制，不喜欢完全的wsgi，所以象pylons的配置也不是我喜欢的，复杂。当然可能与我对pylons理解得不深有关。
>>>
>>> pylons的组件是全部都可以更换的，包括模板引擎（通过配置）、和request、response系统（通过重载PylonsApp）。
>>>
>>
>> 那和我重写也差不多了。
>
> 但是只需要重写相关的部分，其他的部分还可以继续用。这个就类似TurboGears2的做法，把不喜欢的换掉，但底层架子还是Pylons的。这样不用每个web
> framework都重头实现所有的东西了。
问题是我要换的基本上都换了，为什么不基于它的底层werkzeug做呢？更且我要做的并不只是换掉某个组件，更重要的是处理模式，比如：app，dispatch，这些怎么换。因为uliweb是支持wsgi的，所以可以考虑在pylons中运行uliweb这个是可以的。基础并不相同，而且这个已经成为历史。那么我既然对pylons许多东西可以说是不想用或感冒，为什么我会考虑去在pylons中实现。相同的组件结构并不表示框架就是一样的，关键还是思想，更何况许多的组件都不相同。如果说只是基于paste，那么我也可以说是基于werkzeug。这个就更和pylons无关了呀。大家都是用相同的东西做框架，还有什么基于不基于呢？因为基础本来就差不多，可以认为是各自的实现不同而已。
>
>>> django的middleware机制的问题是只能给django使用，而wsgi middleware是可以给所有wsgi app使用的。可复用性完全不一样。
>> 所以wsgi级别的我并不喜欢。wsgi还是太底层，并且以env作为数据传输的接口，在env中放置对象，我不认为是好的做法。
>
> 这个见仁见智。我倒是认为wsgi用一个dict作为环境，在不同组件之间传输信息的做法，非常的简洁，至少比把什么都放到request对象里要强。
request并没有太多的东西，我认为反而是wsgi是一个大杂烩。
>
> 而且既然WSGI已经是Python官方的标准(PEP-333)，是被各种框架支持最好的协议，如果想让自己的代码达到尽可能大的可重用性的话，为什么不支持它呢？
再次声明，uliweb支持wsgi。
>
> 以前在WSGI社区看到一个说法：django middleware considered
> harmful。就是说由于django自己搞了一套middleware机制，使得大量的middleware需要开发两份，一份给django用，一份是wsgi的。如果django
> middleware能够遵从wsgi标准的话，社区的力量就可以更集中了。
对于wsgi的理解不同。所以只能是仁者见仁了。当然，复用并不表示一定要组件级复用，也可以是思想，代码的复用。等有更高层的标准出来可能会更好一些。我还在想，为什么不统一象django一样的middleware呢？我认为可以分为两个层次，一个是wsgi的middleware，一个是app级的middlware，这样更合理。现在uliweb就是这样的。
>
>>> pylons的project目录下是可以有多个app的，每个都是一个python package。像这样：
>>>
>>> project
>>> \ app1
>>> \ app2
>>>
>>> 每个app管理自己的model, controllers, template, static files, etc.
>>>
>>> 在 project/development.ini 中可以用paste.deploy的方式指定 [composite:main] 来将不同的
>>> app 挂载到不同的 url 下，当然你也可以让主app的routes来做这个app dispatch的事情。
>>
>> 还是不清楚。在uliweb中app是组织单位，但是使用时可以看成是一个整体，并且app中的东西可以没有model，view之类的东西。pylons的app是不是一个wsgi的application？这个就和web2py很象，相当于一个运行单位。和uliweb的app不是一个概念。并且url的挂接是对app下的所有url都起作用还是什么的？比如在某个app中定义了/static，在另一个也定义了/static，那么会不会有冲突？感觉不是一个概念，uliweb的是和django接近。
>
> pylons的app是一个wsgi app。其实只要是wsgi app就可以，不一定要有model, view这些东西。
这个就是设计上的不同了。
>
> 有什么页面介绍uliweb中的app吗？组织单位这个概念和建立python
> package名字空间有什么区别呢？我理解的django的app也是有独自的model和view的，他们只是共享一个项目配置和url配置而已。而pylons下的app是自己包含这些东西的，在项目级别只是决定如何挂载各app而已。uliweb的核心应该就是app重用，如果有个详细的介绍会比较好一些。
uliweb的app首先也是一个python的package，它也有__init__.py这个并没有区别。在uliwebproject.appspot.com中体系结构中有介绍。我所说的app是指应用级别的，不是简单的物理结构。并且这个app和django的一样，是可以直接以模板的方式存在，并不需要一定放在apps下，比如有一些内置的app就是放在uliweb.contrib下的，只要可以导入就可以。然后你也可以使用setuptools来安装，并且在uliweb的admin管理中，可以通过pkg_resource来自动找到。当然在安装时entry_point要写正确，才可以找到。这个重用，在9.5上的会课讲了不少。也可以看一看当时的视频。重用包括，代码，配置，静态文件等东西，可以只包含一样或全部包含。所以你可以理解为它是一个可重用的部件，可以是一个真正能运行的单位，也可以是某个单位的一部分可重用的东西。所以它的粒度要小于运行单位。
>
> app的挂载一般是通过url前缀来实现，比如把 wiki app 挂在 /wiki 下，poller app 挂在 /poll
> 下。static file是自己控制的，比如 /wiki/js/ , /poll/js/
> 。如果要想实现所有的静态文件都整合后放在一个目录下，用 paste.cascade.Cascade 这个 wsgi middleware
> 配置一下优先顺序，然后挂载根下就好了。不知道uliweb想要实现的是什么样的功能。
因为目前uliweb一个project相当于一个pylons的app，所以所有的app下的东西都是可以视为是一个整体，不需要考虑挂接，或考虑的方式不同。
>
>>> limodou你能给一个复现问题的用例吗？如果能够到 bugs.python.org 去提交一个 bug report 就更好了，毕竟
>>> cgi 是标准库里的东西，这个东东的质量对整个python社区都很有影响。
>>
>> 当上传文件时，我就是在使用fancyupload时发现的，它是一个flash的上传组件。它结束时并没有回车换行。而webob使用了cig.FieldStorage，它是使用readline()来处理的，结果收不到最后的\r\n'结果会挂起，就是这个问题。而werkzeug在他的blog中写了相关的内容。
>
> 抱歉没有google到那篇blog，能给个地址吗？
这个等我找一找。他是werkzeug的作者也是jinja的作者。
>
>>> 你说的beaker的问题是这个吗？
>>> http://hi.baidu.com/limodou/blog/item/1ab2b17edc3ab4310dd7da01.html
>>>
>>> 不知道你有没有和作者交流过这个问题。另外，你重写的session manager能作为wsgi
>>> middleware发布出来吗？这样其他社区也可以使用你的工作成果了。
>>
>> 交流过 http://bitbucket.org/bbangert/beaker/issue/16/how-to-stop-session-to-create-session-file
>> 还没有被解决。并且不支持rememberme的功能。我的sessionmanager写的是符合uliweb的middleware的东西，但是session库本身是独立的，在uliweb/lib/weto中，可以随便使用。
>
> 看了一下这个issue，感觉上你是希望在request没有操作session的情况下，不要执行session.persist()。我看了一下pylons，pylons是直接使用beaker提供的wsgi
> middleware: beaker.middleware.SessionMiddleware
> ，在这个middleware的__call__()方法可以看到，在start_response时，有一段判断：
>
> if session.dirty() or (session.accessed() and
> self.options.get('auto')):
> session.persist()
>
> 因此，其实直接用 beaker 提供的 middleware 应该就不会有你的困扰。如果你不用他的middleware要自己写的话，用同样的逻辑就可以。
>
> 不知道我是否正确理解了你的问题。
>
这个问题的引起是由于通过api的方式来调用造成的，在api调用时，因为没有上送cookie，所以在后台是根本找不到对应的session文件的，而beaker，为了使用session文件，会先创建锁文件，但是这时是没有必要的。这个问题如果你有兴趣我建议你试一下，因为这是别人在使用uliewb时遇到的，我自已也重新过，所以才重写了weto模块。
>>> 哦，我以为你说的是django那个admin界面。
>>> 设置这种事情还是用配置文件最简单，需要使用工具来做吗？
>>
>> DRY
>
> 用配置文件不DRY吗？
我是说配置过程可以不用DRY，有个界面辅助不是更好。对于喜欢手动的当然没用了。
>
>>> 在view中可以不带request,response参数，模板自动映射
>>> 这两个是指？
>>
>> 比如定义一个view函数，可以：
>>
>> def index():
>> return {}
>>
>> 没有传入request，但是却可以直接在index中使用
>
> pylons也是这样的啊，在模块顶部 from pylons import request 就行了，不需要把 request 传入函数。那是django的做法。
>
连这个都不用。
>> 如果一个view返回dict则框架会自动查找与view函数同名的模板文件进行处理。而不用手工去指定了。
>
> 这个在lib/base.py重载一下 WSGIController._dispatch_call() 就 ok 了：
>
> class BaseController(WSGIController):
> def _dispatch_call(self):
> response = WSGIController._dispatch_call(self)
> if isinstance(response, dict):
> response =
> render('/'+request.environ['pylons.routes_dict']['action']+'.mako',
> response)
> return response
>
> 这样所有的action就都支持这个功能了。
>
这个不是要改代码？并不是框架本身支持的。
>> 其实还是有许多的选择和设计不同的。
>
> 没错，不同的选择会导致不同的设计。我自己也会没事写框架玩，这个很正常。
>
> 我回复这个thread其实是想说：做框架不如做库，做只能给一个框架用的库不如做wsgi库。werkzeug就是一个很好的例子，他把自己开发过程中做的工作，基本上都用wsgi的方式单独发布出来了，他自己本身并不是一个框架，而是一堆轮子，和Paste类似。所以在其他的项目中，包括Pylons，使用他的东西就几乎没有任何障碍，对整个社区都是有好处的。
>
但是库已经有了，我认为werkzeug不错。而wsgi库，目前我认为uliweb中的东西还没有什么特别需要做成wsgi的东西，我是以库的形式做的，象weto。所以我使用werkzeug，为什么还要基于pylons呢？我做框架是为了开发按我思路的web，而不是只是让别人拿uliweb去做一个框架。既然别人要做，我想我可以做得更好。
23号
2009/9/30 limodou <lim...@gmail.com>:
--
--
Best Regards
----
My Chaos: http://n23.appspot.com
ming_cuhk
On Sep 26, 11:01 am, 光风 <breeze.guangf...@gmail.com> wrote:
> Emacs党奸笑路过
>
> 2009/9/25 smallfish <smallfish...@gmail.com>
>
> > 坚持自己，偶用VIM！
>
> > --
> > 如果不能改变结果 那就完善过程
> >http://hi.baidu.com/smallfish_xy
> >http://blog.csdn.net/smallfish_xy
>
> > 2009/9/25 way wrong <wrongwa...@gmail.com>
>
> > 之前见刘鑫同学大力鼓吹emacs，俺两个月前小心地尝试同时用netbeans和emacs，现在基本上已开始学会享受emacs带来的便捷与乐趣了。
>
> >> 接下来，开始尝试刘鑫同学大力鼓吹的pgSQL.
>
> >> 2009/9/25 刘鑫 <march....@gmail.com>
>
> >>> 2009/9/25 四不象 <tabris17...@gmail.com>
>
> >>>> 最后还是决定用mysql了，pg以前没用过，还是先学习下再进行实际应用吧。
> >>>> 不过我决定把某表主键从BIGINT改回INT了，如果真的碰到INT主键耗尽，那就说明该换数据库了:)
>
> >>> 数据库的选项也是个比较重要的事，支持谨慎选择，积极比较的作法：）。
>
> >>>> ----- Original Message -----
> >>>> *From:* @@ <ask...@gmail.com>
> >>>> *To:* pyth...@googlegroups.com
> >>>> *Sent:* Friday, September 25, 2009 2:34 PM
> >>>> *Subject:* [CPyUG:101845] Re: sqlalchemy、storm和web2py dal的比较报告
>
> >>>> 也得看服务器吧。。
> >>>> 我开始想试试pg的 不过发现mysql一个现有的库 转到pg 一点也不容易。。弄了1 2天 放弃了。。
>
> >>>> 关键是facebook这样的都选的是mysql。。。
> >>>> google也是为mysql出过patch，没看到他为pg出patch（也许有 没看到）
>
> >>>> 2009/9/25 刘鑫 <march....@gmail.com>
>
> >>>>> 2009/9/25 四不象 <tabris17.cn@ <tabris17...@gmail.com>gmail.com>
>
> >>>>>> 这个数据库还没在项目中用过，听说很牛X，不过好像性能方面被人诟病，不知道用在大型网站的CMS系统中合不合适
>
> >>>>> 跟你说个笑话吧，我们这边儿有个MySQL的应用，几经优化，日处理量还是卡在二百万（我信任同事在MySQL优化方面的水平，这种海量数据的处理经验，在一般公司不容易见到）左右。
>
> >>>>> 我在网上搜了一下，有个老外去年发过一封邮件，大意是：此人自称PG菜鸟，建了一个跟我们的应用类似的东西（那张表比我们的还复杂多了），在未经优化的情况下，日处理量卡在了八百万左右，上来问问大家怎么优化......
>
> >>> --
> >>> 光见贼吃肉，没见贼挨打。
> >>> ......
>
> >>> 劉鑫
> >>> March.Liu
>
>
benluo
> 偶也用vim, 其实一直想尝试emacs, 但是担心vim转到emacs的成本太高
> 不过pg的确用的很爽, 自己感觉用起来比mysql 靠普
vim 和 emacs 都是靠谱的东西，用好一个就不错了。贪多等于什么也没学会。我觉得emacs 对 html/css/js 的支持还是不够。
现在基于 web 的程序越来越多了。vim 就不清楚了。