Python的组件架构扩展

[潘俊勇]

微软有COM组件架构，使用接口来拼装应用，很牛。
对于复杂应用，组件架构大大简化了开发过程，系统更可扩展，柔性更强。

Python上是否有类似的成熟体系？

有的，twisted在用，zope在用，还有很多知名的python软件都在用....

那就是著名的Zope Component Architecture，来自于Zope社区的一个系统，却已经在整个python社区开花结果
了。。。。

发展了若干年的宝物在这里：

http://www.muthukadan.net/docs/zca.html

（绝对不是新鲜玩意了，如果您还不知道，责任不在您，只怪zope社区广告没做好）

即便你做非web的程序，这个也是试用你的，上的例子就是基于pyGTK的。

很简单的概念(适配器、工具)，却容下了各种设计模式的纷繁内容，秉承了python"大道至简"的理念。

如果你只想作python脚本级别的开发，这个您可能不那么需要ZCA；

如果您是真正的pythoner开发人员，ZCA绝对是不得不学的附加，我超强力推荐！

广告到此结束。

（如果有人想翻译上面的文章，和俺联系）

[leopay]

不错哦，谢谢分享

2008/8/27 潘俊勇 <panju...@gmail.com>

[Zoom.Quiet]

2008/8/27 潘俊勇 <panju...@gmail.com>:

> 微软有COM组件架构，使用接口来拼装应用，很牛。
> 对于复杂应用，组件架构大大简化了开发过程，系统更可扩展，柔性更强。
>

又见老潘,怎么不忽悠自个儿的 czug* 列表了?!

> Python上是否有类似的成熟体系？
>
> 有的，twisted在用，zope在用，还有很多知名的python软件都在用....
>
> 那就是著名的Zope Component Architecture，来自于Zope社区的一个系统，却已经在整个python社区开花结果
> 了。。。。
>
> 发展了若干年的宝物在这里：
>
> http://www.muthukadan.net/docs/zca.html
>
> （绝对不是新鲜玩意了，如果您还不知道，责任不在您，只怪zope社区广告没做好）
>
> 即便你做非web的程序，这个也是试用你的，上的例子就是基于pyGTK的。
>
> 很简单的概念(适配器、工具)，却容下了各种设计模式的纷繁内容，秉承了python"大道至简"的理念。
>
> 如果你只想作python脚本级别的开发，这个您可能不那么需要ZCA；
>
> 如果您是真正的pythoner开发人员，ZCA绝对是不得不学的附加，我超强力推荐！
>
> 广告到此结束。
>
> （如果有人想翻译上面的文章，和俺联系）

俺先报名了!
建议到 OBP 工程环境来统一组织...

--

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''

[vicalloy]

COM给我的感觉就是接口，主要是用来在windows实现不同开发语言间组件的公用。如果只是同一种开发语言，似乎没多少使用COM的必要。
ZCA我没怎么看过，不过zope在ZCA里实现了一个类似Interface的东西，让我觉得有些怪怪的感觉。
Interface应当是语言支持的范畴，如果有需要应当由python来支持。

在 08-8-27，潘俊勇<panju...@gmail.com> 写道：

[潘俊勇]

微软的COM太复杂了，ZCA简单很多。

没有COM就没有Windows。

你可能到处在使用COM，但是并不会去作COM自身的组件开发。

的确，小的简单的应用，极有可能不需要组件架构的。

但是，稍微复杂一些的，组件架构就非常有必要了。
组件架构更考虑可重用性。

一旦设计好，从用的角度，你自己可以选很多组件，装配上就用，而且用得不爽就可以换掉，而且不改源代码，就可以加很多新的功能，这就是爽的所在。

比如limodou的unipad，我觉得如果用组件架构，就可能会更加清晰。

On 8月27日, 上午9时41分, vicalloy <zbir...@gmail.com> wrote:
> COM给我的感觉就是接口，主要是用来在windows实现不同开发语言间组件的公用。如果只是同一种开发语言，似乎没多少使用COM的必要。
> ZCA我没怎么看过，不过zope在ZCA里实现了一个类似Interface的东西，让我觉得有些怪怪的感觉。
> Interface应当是语言支持的范畴，如果有需要应当由python来支持。
>

> 在 08-8-27，潘俊勇<panjuny...@gmail.com> 写道：

[风翔万里]

别故弄玄虚的，告诉我们他能为客户带来什么价值？能提高多少开发效率，好让我们不用加班？在不添加硬件的情况下提高多少程序性能，能让我们降低多少实施
成本，提高多少方案利润？

[vicalloy]

不是说组件不重要。
只是觉得那个Interface诡异了点。
而且看它的作用确实也和Interface差不多，换句话说，ZCA是在以Java的哲学进行python开发。
当然我没去认真了解过ZCA，这只是我主观的感觉。

在 08-8-27，潘俊勇<panju...@gmail.com> 写道：

[vicalloy]

风翔万里给我的感觉，每次说话都很牛X。
这是社区，大家在这里交流/消遣，但没人有责任来教你啥。
老大只是给出一个参考，给出一个线索，具体怎么样还需要自己把握。

在 08-8-27，风翔万里<cnfa...@gmail.com> 写道：

[潘俊勇]

呵呵，实用主义：）

类似python，你想想decorator能给客户带来什么价值？

这么说吧，

如果你是搞架构设计的，还知道一些设计模式，想去实践，做一个内部布置得体、生命力强的漂亮软件，那么ZCA无疑是你的最佳选择。

如果你根本不高什么架构设计，也不懂不关心什么设计模式，反正就是想做那只能逮住老鼠的花猫，那么你一定有拿来主义的思想，那么你不会考虑再造轮子，那
么你可以去网上选择现有的ZCA组件，方便为你所用。如同你可以选择各种windows控件那样。。。

to zoomq:

这里人多，好做广告。。。czug最近的确灌溉不多了....

[HG]

我第一次看见Zope里面的Interface的时候非常别扭，
后来在twisted里面看见的时候，没有那么反感，但是还是觉得可有可无
毕竟没有涉足过组件这类的领域
不过后来学习grok的时候再次发现了他的魅力，仅仅是interface一项，
更加别说ZCA，其实话说回来，还是得感谢组件结构的这种思想，
而Python恰好又有这样的实现，DRY，所以希望利用组件结构的pyer
ZCA就是首选，对我而言更是必选

2008/8/27 vicalloy <zbi...@gmail.com>

[Zoom.Quiet]

2008/8/27 HG <hac...@gmail.com>:

> 我第一次看见Zope里面的Interface的时候非常别扭，
> 后来在twisted里面看见的时候，没有那么反感，但是还是觉得可有可无
> 毕竟没有涉足过组件这类的领域
> 不过后来学习grok的时候再次发现了他的魅力，仅仅是interface一项，
> 更加别说ZCA，其实话说回来，还是得感谢组件结构的这种思想，
> 而Python恰好又有这样的实现，DRY，所以希望利用组件结构的pyer
> ZCA就是首选，对我而言更是必选
>

分享一下具体体验哪,,,,,

大抽象的东西,理解再通,具体到代码来时,一样冇头绪的哪!

马上 OpenSourceCamp 要举行了 EveryDo 团队,就SaaS,Zope3 ZCA 可以提出好些议题的!
建议进行准备先,
俺只有Pythonic 教育/过程改进方面的体验可以分享,,,

>
> 2008/8/27 vicalloy <zbi...@gmail.com>
>>
>> 风翔万里给我的感觉，每次说话都很牛X。
>> 这是社区，大家在这里交流/消遣，但没人有责任来教你啥。
>> 老大只是给出一个参考，给出一个线索，具体怎么样还需要自己把握。
>>
>> 在 08-8-27，风翔万里<cnfa...@gmail.com> 写道：
>> > 别故弄玄虚的，告诉我们他能为客户带来什么价值？能提高多少开发效率，好让我们不用加班？在不添加硬件的情况下提高多少程序性能，能让我们降低多少实施
>> > 成本，提高多少方案利润？

--

[潘俊勇]

举一个例子：

比如你设计了一个登录认证系统，输入用户名、口令，登录。

ok，很简单，搞定了。

过2天，你们老板说，让有gmail帐号的人，也能够登录。。。

能力超强的你，研究了gmail协议，happy hacking，完成了。

过了2天，你老板说windows活动目录上的人，也能够登录。。。

ok，算你狠，苦苦研究ldap协议，有搞定了，我也牛。。。

然后，时代变迁，大家开始用openid登录了

上帝啊，难道我又要...

那么组件架构可以解决这个问题，让你根据接口每次写一个插件就行了，每个插件而且可以重用。你可以去网上下载很多插件即可...

On 8月27日, 上午10时25分, vicalloy <zbir...@gmail.com> wrote:
> 风翔万里给我的感觉，每次说话都很牛X。
> 这是社区，大家在这里交流/消遣，但没人有责任来教你啥。
> 老大只是给出一个参考，给出一个线索，具体怎么样还需要自己把握。
>

> 在 08-8-27，风翔万里<cnfa2...@gmail.com> 写道：

[limodou]

2008/8/27 潘俊勇 <panju...@gmail.com>:

> 举一个例子：
>
> 比如你设计了一个登录认证系统，输入用户名、口令，登录。
>
> ok，很简单，搞定了。
>
> 过2天，你们老板说，让有gmail帐号的人，也能够登录。。。
>
> 能力超强的你，研究了gmail协议，happy hacking，完成了。
>
> 过了2天，你老板说windows活动目录上的人，也能够登录。。。
>
> ok，算你狠，苦苦研究ldap协议，有搞定了，我也牛。。。
>
> 然后，时代变迁，大家开始用openid登录了
>
> 上帝啊，难道我又要...
>
> 那么组件架构可以解决这个问题，让你根据接口每次写一个插件就行了，每个插件而且可以重用。你可以去网上下载很多插件即可...
>

上面只让我看到了接口的标准化，在python中虽然没有强调interface，但是duck
type还是用的，比如file-like对象，只要有write,
read之类的就可以使用。只不过不象interface这样比较明确罢了。但如果只是因为interface把原本不明确的使用转为明确的定义，我认为只是定义上的严格，并不是太革命性的东西。

而且interface与baseclass也有类似的地方，我把interface改为某个基类效果差不多，就象c++中的抽象类一样。虽然定义不同，但是在某些方面可以做得差不多。

--
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

[风翔万里]

刚到您的blog转了一圈，问点基础问题：
1、是不是用了zope后可以替代tomcat和apache这些web服务器了，python_mod是不是也不需要了？如果我有应用已经用了
python_mod是不是要去掉后才能移植？
2、zope的web服务是用什么语言实现的？
3、上文提到的Component是不是主要针对zope平台上的组件开发的？
4、zope上面是不是只能跑python的应用，php\jsp都不行？

> > > 成本，提高多少方案利润？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[风翔万里]

zope的均衡负载支持多服务器共享session吗？如果不支持，他的均衡负载主要是干什么的哪？

> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Albert Lee]

2008/8/27 风翔万里 <cnfa...@gmail.com>:
> 刚到您的blog转了一圈，问点基础问题：

> 4、zope上面是不是只能跑python的应用，php\jsp都不行？
zope 是一个应用服务器，上面跑python。 难道tomcat，jboss 上也要跑 php么？
php和jsp那些可以通过前面加apache来与zope协同。另外，好像zope中确实有方法调用php的。

>
>

[刘鑫]

这几个问题明明应该是为google准备的……

2008/8/27 风翔万里 <cnfa...@gmail.com>

刚到您的blog转了一圈，问点基础问题：
1、是不是用了zope后可以替代tomcat和apache这些web服务器了，python_mod是不是也不需要了？如果我有应用已经用了
python_mod是不是要去掉后才能移植？
2、zope的web服务是用什么语言实现的？
3、上文提到的Component是不是主要针对zope平台上的组件开发的？
4、zope上面是不是只能跑python的应用，php\jsp都不行？

--
站着说话不腰疼，于是中国人民都站起来
说话了
……

劉鑫
March.Liu

[Chen Houwu]

我补充一下：
1. zca中的interface对接口的定义不是强制性的，而是描述性的。
2. interface不仅具有明确定义的功能，更重要的是，它是其他技术的基础：
（1）zca提供了依赖注射和aop能力
（2）zca提供了规约式编程能力：前件、后件、不变式什么的
（3）zca提供了事件发布机制
（4）zca提供了常用设计模式
（5）。。。。。很多，一时想不起来了

3. zca的一个主导原则是：不要subclass，要delegate，并根据zope2的经验认为前者是造成模块重用的巨大障碍，所以整个zca
都是建立在adapter模式上的。虽然有人认为在这方面，做得太绝对化，有时候带来了不必要的麻烦，但是确实在这个框架下开发组件做到了"高内聚低耦
合"。

4.拿zca和com比是不恰当的。com做到了语言无关，zca只是个开发框架。

学习了zca之后，再用spring.net, castle windsor之流，都是那么的看不上眼。在.net/java世界里，需要多个框架一
起解决的问题，一个zca就可以搞定，而且浑然一体、干净清爽。

觉得zca不够pythonic的人，真的应该考虑一下他每项技术要解决的问题是什么，你是否还有比它更干净的解决办法。


On 8月27日, 上午10时52分, limodou <limo...@gmail.com> wrote:
> 2008/8/27 潘俊勇 <panjuny...@gmail.com>:

>
>
>
>
>
> > 举一个例子：
>
> > 比如你设计了一个登录认证系统，输入用户名、口令，登录。
>
> > ok，很简单，搞定了。
>
> > 过2天，你们老板说，让有gmail帐号的人，也能够登录。。。
>
> > 能力超强的你，研究了gmail协议，happy hacking，完成了。
>
> > 过了2天，你老板说windows活动目录上的人，也能够登录。。。
>
> > ok，算你狠，苦苦研究ldap协议，有搞定了，我也牛。。。
>
> > 然后，时代变迁，大家开始用openid登录了
>
> > 上帝啊，难道我又要...
>
> > 那么组件架构可以解决这个问题，让你根据接口每次写一个插件就行了，每个插件而且可以重用。你可以去网上下载很多插件即可...
>
> 上面只让我看到了接口的标准化，在python中虽然没有强调interface，但是duck
> type还是用的，比如file-like对象，只要有write,

> read之类的就可以使用。只不过不象interface这样比较明确罢了。但如果只是因为interface把原本不明确的使用转为明确的定义，我认为只是定-义上的严格，并不是太革命性的东西。
>
> 而且interface与baseclass也有类似的地方，我把interface改为某个基类效果差不多，就象c++中的抽象类一样。虽然定义不同，但是在-某些方面可以做得差不多。

>
> --
> 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- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[liu wen]

好东西应该支持。一次开发。多次复用。说白了是个功能组件。不要上纲上线

2008/8/27 Chen Houwu <chen...@gmail.com>

[Zoom.Quiet]

2008/8/27 Chen Houwu <chen...@gmail.com>:
> 我补充一下：

收录:
http://wiki.woodpecker.org.cn/moin/ZopeComponentArchitecture

readPath: 首页->PyWebFrameList(WEB应用框架纵览)->

--

http://zoomquiet.org'''

[潘俊勇]

On 8月27日, 上午10时52分, limodou <limo...@gmail.com> wrote:
> 2008/8/27 潘俊勇 <panjuny...@gmail.com>:
>
>
>

> > 举一个例子：
>
> > 比如你设计了一个登录认证系统，输入用户名、口令，登录。
>
> > ok，很简单，搞定了。
>
> > 过2天，你们老板说，让有gmail帐号的人，也能够登录。。。
>
> > 能力超强的你，研究了gmail协议，happy hacking，完成了。
>
> > 过了2天，你老板说windows活动目录上的人，也能够登录。。。
>
> > ok，算你狠，苦苦研究ldap协议，有搞定了，我也牛。。。
>
> > 然后，时代变迁，大家开始用openid登录了
>
> > 上帝啊，难道我又要...
>
> > 那么组件架构可以解决这个问题，让你根据接口每次写一个插件就行了，每个插件而且可以重用。你可以去网上下载很多插件即可...
>
> 上面只让我看到了接口的标准化，在python中虽然没有强调interface，但是duck
> type还是用的，比如file-like对象，只要有write,
> read之类的就可以使用。只不过不象interface这样比较明确罢了。但如果只是因为interface把原本不明确的使用转为明确的定义，我认为只是定义上的严格，并不是太革命性的东西。
>

关于接口，的确python是已经在用的，只是没有明晰化。

但是一旦使用ZCA，会自带一个内存注册表，可以记录：

- 那些组件实现了那些接口
- 接口之间该如何转换

有了这个注册表，你可以实现：

- 得到一个实现数据量连接对象IDBConnection的对象，程序中可完全不考虑这个是采用mysql还是sqlite
- 接口转换，就如同类型转换一样傻瓜：

我们知道 str(33) 转换成了 '33'

那么，接口也有类似的功效，比如 IInterfaceB(obj) 可以自动将obj适配出一个新的InterfaceB，适配是扩增对象功能的
基本方法。

上面2点，也就是ZCA的核心：工具Utility和适配Utility，当然还有事件机制，这些都非常有用的。接口是实现这些的基础。

（说这些，是希望招人的时候，能有知道ZCA的人士出现啊。。。）

[@@]

eclipse的RCP是不是有这套东西。 adapter注册什么的

2008/8/27 潘俊勇 <panju...@gmail.com>

[Zoom.Quiet]

2008/8/27 @@ <ask...@gmail.com>:
> eclipse的RCP是不是有这套东西。 adapter注册什么的
>
大哥,这是举例, ZCA 绝对不只作登录的,
如果你的应用要面对,不同的DB/网络/硬件/服务/外部应用,,,,
而且都不知道什么时候哪儿块有变化,
基于组件的开发就有谱的多,

俺的理解,这是将软件开发 乐高枳木化的又一种思想,
可素,真的可行?
别的不说, ZCA 的组件仓库有 CPAN 的级别嘛?

--

[Zoom.Quiet]

2008/8/27 潘俊勇 <panju...@gmail.com>:

KAO! 那不是露题嘛?!?!我们将你说的背下来,不就可能成功了?

[@@]

2008/8/27 Zoom. Quiet <zoom....@gmail.com>

2008/8/27 @@ <ask...@gmail.com>:
> eclipse的RCP是不是有这套东西。 adapter注册什么的
>
大哥,这是举例, ZCA 绝对不只作登录的,
如果你的应用要面对,不同的DB/网络/硬件/服务/外部应用,,,,
而且都不知道什么时候哪儿块有变化,
基于组件的开发就有谱的多,

俺的理解,这是将软件开发 乐高枳木化的又一种思想,
可素,真的可行?
别的不说, ZCA 的组件仓库有 CPAN 的级别嘛?

大妈 我说的和登录也没关系啊

RCP中的 Interface  adapter

[匡东]

我不是很看好Zope，这个东西比Django好像出来得早多了，上世纪我就玩过了，而Django是近几年才出现的。但感觉Django比Zope发展的要好。如果大家觉得自己时间比较不值钱的话，可以学学。

http://www.google.com/trends?q=zope%2Cdjango%2CQuixote&ctab=0&geo=all&date=all&sort=0

2008/8/27 @@ <ask...@gmail.com>

--
少则多，慢则快，柔则刚。

[limodou]

2008/8/27 Chen Houwu <chen...@gmail.com>:

> 我补充一下：
> 1. zca中的interface对接口的定义不是强制性的，而是描述性的。
> 2. interface不仅具有明确定义的功能，更重要的是，它是其他技术的基础：
> （1）zca提供了依赖注射和aop能力
> （2）zca提供了规约式编程能力：前件、后件、不变式什么的
> （3）zca提供了事件发布机制
> （4）zca提供了常用设计模式
> （5）。。。。。很多，一时想不起来了
>
> 3. zca的一个主导原则是：不要subclass，要delegate，并根据zope2的经验认为前者是造成模块重用的巨大障碍，所以整个zca
> 都是建立在adapter模式上的。虽然有人认为在这方面，做得太绝对化，有时候带来了不必要的麻烦，但是确实在这个框架下开发组件做到了"高内聚低耦
> 合"。
>
> 4.拿zca和com比是不恰当的。com做到了语言无关，zca只是个开发框架。
>
> 学习了zca之后，再用spring.net, castle windsor之流，都是那么的看不上眼。在.net/java世界里，需要多个框架一
> 起解决的问题，一个zca就可以搞定，而且浑然一体、干净清爽。
>
> 觉得zca不够pythonic的人，真的应该考虑一下他每项技术要解决的问题是什么，你是否还有比它更干净的解决办法。

这些东西都很抽象，有没有用zca解决的非zope开发的实例？
看得上不上眼那是个人理解的问题，至少因为不懂zca，仅从一些描述还无法体会。

[潘俊勇]

On 8月27日, 下午2时38分, limodou <limo...@gmail.com> wrote:
> 2008/8/27 Chen Houwu <chenho...@gmail.com>:

>
>
>
> > 我补充一下：
> > 1. zca中的interface对接口的定义不是强制性的，而是描述性的。
> > 2. interface不仅具有明确定义的功能，更重要的是，它是其他技术的基础：
> > （1）zca提供了依赖注射和aop能力
> > （2）zca提供了规约式编程能力：前件、后件、不变式什么的
> > （3）zca提供了事件发布机制
> > （4）zca提供了常用设计模式
> > （5）。。。。。很多，一时想不起来了
>
> > 3. zca的一个主导原则是：不要subclass，要delegate，并根据zope2的经验认为前者是造成模块重用的巨大障碍，所以整个zca
> > 都是建立在adapter模式上的。虽然有人认为在这方面，做得太绝对化，有时候带来了不必要的麻烦，但是确实在这个框架下开发组件做到了"高内聚低耦
> > 合"。
>
> > 4.拿zca和com比是不恰当的。com做到了语言无关，zca只是个开发框架。
>
> > 学习了zca之后，再用spring.net, castle windsor之流，都是那么的看不上眼。在.net/java世界里，需要多个框架一
> > 起解决的问题，一个zca就可以搞定，而且浑然一体、干净清爽。
>
> > 觉得zca不够pythonic的人，真的应该考虑一下他每项技术要解决的问题是什么，你是否还有比它更干净的解决办法。
>
> 这些东西都很抽象，有没有用zca解决的非zope开发的实例？

有的啊，那篇文章上，就自带的一个例子，做的是一个本地的桌面应用程序，和limodou你的估计有很多相近之处的，你看看肯定会有启发

[limodou]

2008/8/27 Zoom. Quiet <zoom....@gmail.com>:

> 2008/8/27 @@ <ask...@gmail.com>:
>> eclipse的RCP是不是有这套东西。 adapter注册什么的
>>
> 大哥,这是举例, ZCA 绝对不只作登录的,
> 如果你的应用要面对,不同的DB/网络/硬件/服务/外部应用,,,,
> 而且都不知道什么时候哪儿块有变化,
> 基于组件的开发就有谱的多,
>
> 俺的理解,这是将软件开发 乐高枳木化的又一种思想,
> 可素,真的可行?
> 别的不说, ZCA 的组件仓库有 CPAN 的级别嘛?

interface好还是subclass好，这个东西我不好评判。我只知道java为什么有interface，因为它不支持多重继承。而c++支持多重继承，它不需要interface。但我认为关键是语言本身是否支持。

interface与class有多大的差异？

如果差别不大的话，新意在哪里？

[limodou]

2008/8/27 潘俊勇 <panju...@gmail.com>:

>
>
> On 8月27日, 下午2时38分, limodou <limo...@gmail.com> wrote:
>> 2008/8/27 Chen Houwu <chenho...@gmail.com>:
>>
>>
>>
>> > 我补充一下：
>> > 1. zca中的interface对接口的定义不是强制性的，而是描述性的。
>> > 2. interface不仅具有明确定义的功能，更重要的是，它是其他技术的基础：
>> > （1）zca提供了依赖注射和aop能力
>> > （2）zca提供了规约式编程能力：前件、后件、不变式什么的
>> > （3）zca提供了事件发布机制
>> > （4）zca提供了常用设计模式
>> > （5）。。。。。很多，一时想不起来了
>>
>> > 3. zca的一个主导原则是：不要subclass，要delegate，并根据zope2的经验认为前者是造成模块重用的巨大障碍，所以整个zca
>> > 都是建立在adapter模式上的。虽然有人认为在这方面，做得太绝对化，有时候带来了不必要的麻烦，但是确实在这个框架下开发组件做到了"高内聚低耦
>> > 合"。
>>
>> > 4.拿zca和com比是不恰当的。com做到了语言无关，zca只是个开发框架。
>>
>> > 学习了zca之后，再用spring.net, castle windsor之流，都是那么的看不上眼。在.net/java世界里，需要多个框架一
>> > 起解决的问题，一个zca就可以搞定，而且浑然一体、干净清爽。
>>
>> > 觉得zca不够pythonic的人，真的应该考虑一下他每项技术要解决的问题是什么，你是否还有比它更干净的解决办法。
>>
>> 这些东西都很抽象，有没有用zca解决的非zope开发的实例？
>
> 有的啊，那篇文章上，就自带的一个例子，做的是一个本地的桌面应用程序，和limodou你的估计有很多相近之处的，你看看肯定会有启发
>

我把例子简单地看了一下，体会如下：

文章上举的例子(desk)是通过ZCA来处理不同的数据源，如zodb和sqlite3，因此它通过zca作了一个封装。在程序启动时根据命令行（check_use_relational_db()）不同来调用不同的初始化处理

if use_rdb:
initialize_rdb()
else:
initialize_odb()

不同的初始化将进行相应的组件的注册。然后在程序中通过象getUtility(IRelationalDatabase)之类的调用得到当时注册的对象进行处理。

而zca提供的重要的功能：

interface等类定义
注册机制
获取机制
配置机制

因此只有当你程序有些组件需要考虑作成可替换，并且可配置时，使用zca是一个选择。

因此我个人的理解：

zca的注册，获取，配置的功能远大于interface。interface改为class也差不多，只不过interface可能有象java一样的检查功能，这一点可能要优于简单的class。但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我看到了java再现。可能对于大型的团队开发的意义要大于为了爱好而编程的小团体。

ulipad的mixin机制与zca还是不同。使用zca，你是在程序只对其进行使用，并不是对当前的类进行扩展。而ulipad的mixin是可以对某个类的属性，方法进行扩展。而ulipad中的plugin工作方式与zca差不多。整个ulipad也有类似zca的注册，获取，配置的机制。不过我还不清楚zca中的plugin机制(类似这个的机制)是如果工作的，比如在ulipad中，你在某个类中定义了一个plugin调用，然后根据调用的不同api对plugin的处理有所区别：

callplugin表示按顺序调用，直到处理到最后一个，无返回值
execplugin表示按顺序调用，但如果中间有函数返回非None时立即退出，并返回这个值

同时一个plugin调用点可以对应多个plugin的处理函数，是一对多的关系。这一点我在zca的例子中没有看得太清楚。

所以ulipad中的mixin技术不主要是为了组件的配置，更多的是为了功能的扩展，是合并，对处理，对类的扩展。如果说在ulipad中应用zca的话，要考虑：

如何使用zca对类进行扩展
如何处理callplugin和execplugin这两种机制

[潘俊勇]

On 8月27日, 下午3时29分, limodou <limo...@gmail.com> wrote:
> 2008/8/27 潘俊勇 <panjuny...@gmail.com>:
>
>
>
>
>

恩，这个就是Utility，很简单的

>
> 而zca提供的重要的功能：
>
> interface等类定义
> 注册机制
> 获取机制
> 配置机制
>
> 因此只有当你程序有些组件需要考虑作成可替换，并且可配置时，使用zca是一个选择。
>

其实，不仅仅是可替换。可重用，以及简化也是。
多个相似的功能，用同一个接口抽象，对于接口的应用方，会简化很多。
这个也可以用相同的父类来处理。只是需要直接进行子类的初始化，代码的耦合会大很多。

> 因此我个人的理解：
>
> zca的注册，获取，配置的功能远大于interface。interface改为class也差不多，只不过interface可能有象java一样的检查功能，这一点可能要优于简单的class。但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我看到了java再现。可能对于大型的团队开发的意义要大于为了爱好而编程的小团体。
>

zope的interface不严格的，不需要和实现完全一致。偷懒的话，实际上你只需要写类名就可以了。
这个和java不同。

> ulipad的mixin机制与zca还是不同。使用zca，你是在程序只对其进行使用，并不是对当前的类进行扩展。而ulipad的mixin是可以对某个类的属性，方法进行扩展。而ulipad中的plugin工作方式与zca差不多。整个ulipad也有类似zca的注册，获取，配置的机制。不过我还不清楚zca中的plugin机制(类似这个的机制)是如果工作的，比如在ulipad中，你在某个类中定义了一个plugin调用，然后根据调用的不同api对plugin的处理有所区别：
>
> callplugin表示按顺序调用，直到处理到最后一个，无返回值
> execplugin表示按顺序调用，但如果中间有函数返回非None时立即退出，并返回这个值
>
> 同时一个plugin调用点可以对应多个plugin的处理函数，是一对多的关系。这一点我在zca的例子中没有看得太清楚。
>
> 所以ulipad中的mixin技术不主要是为了组件的配置，更多的是为了功能的扩展，是合并，对处理，对类的扩展。如果说在ulipad中应用zca的话，要考虑：
>
> 如何使用zca对类进行扩展
> 如何处理callplugin和execplugin这两种机制
>

对unipad不熟悉，但是适配的概念，可以让程序依赖扁平话，会很少出现多层的基层，耦合降低，程序更清晰，测试起来也更方便的。

其实熟悉设计模式的人会喜欢ZCA的。

看看Zope2就知道不用ZCA的问题。无数个父类，子类的功能无限膨胀，出现问题都不知道是哪里的了。

[潘俊勇]

对了，其实不用ZCA一定能够解决问题。

比如unipad肯定有自己的一套方法。

但是，ZCA只是提供了一套标准的方法。

学会了这个，如果大家都用这个方法，就好维护了。

On 8月27日, 下午3时29分, limodou <limo...@gmail.com> wrote:
> 2008/8/27 潘俊勇 <panjuny...@gmail.com>:
>
>
>
>
>

[Zoom.Quiet]

2008/8/27 潘俊勇 <panju...@gmail.com>:

> 对了，其实不用ZCA一定能够解决问题。
>
> 比如unipad肯定有自己的一套方法。
>
> 但是，ZCA只是提供了一套标准的方法。
>
> 学会了这个，如果大家都用这个方法，就好维护了。
>

是也乎,是也乎,这是关键,
在传教未成功前,这种机制就没有用,
但是使用机制来减少开发复杂度的前提又是得足够多的人理解和使用,以及不断增补,
又是个基础模块的自举难题,,,,

--

http://zoomquiet.org'''

[Zoom.Quiet]

2008/8/27 潘俊勇 <panju...@gmail.com>:
>
全程记要:
http://wiki.woodpecker.org.cn/moin/ZopeComponentArchitecture

--

http://zoomquiet.org'''

[limodou]

> 其实，不仅仅是可替换。可重用，以及简化也是。
> 多个相似的功能，用同一个接口抽象，对于接口的应用方，会简化很多。
> 这个也可以用相同的父类来处理。只是需要直接进行子类的初始化，代码的耦合会大很多。

interface并不负责初始化，这是用户要做的事，并不会减少。使用子类也是一样的。而是否是耦合要看你如何使用interface。我看例子中更多的是如何获取一个utility，然后使用它，因此它并不是继承的关系。而直接使用类也是一样的。在我看来interface只关心调用的接口，并不关系调用者如何。从这个意义上来说，使用类也一样。因此只是从interface角度来说，我看区别不大。

>
>> 因此我个人的理解：
>>
>> zca的注册，获取，配置的功能远大于interface。interface改为class也差不多，只不过interface可能有象java一样的检查功能，这一点可能要优于简单的class。但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我看到了java再现。可能对于大型的团队开发的意义要大于为了爱好而编程的小团体。
>>
>
> zope的interface不严格的，不需要和实现完全一致。偷懒的话，实际上你只需要写类名就可以了。
> 这个和java不同。

如果只写一个类名，与类更是没有区别了。更是失去了interface的意义了。

>
>> ulipad的mixin机制与zca还是不同。使用zca，你是在程序只对其进行使用，并不是对当前的类进行扩展。而ulipad的mixin是可以对某个类的属性，方法进行扩展。而ulipad中的plugin工作方式与zca差不多。整个ulipad也有类似zca的注册，获取，配置的机制。不过我还不清楚zca中的plugin机制(类似这个的机制)是如果工作的，比如在ulipad中，你在某个类中定义了一个plugin调用，然后根据调用的不同api对plugin的处理有所区别：
>>
>> callplugin表示按顺序调用，直到处理到最后一个，无返回值
>> execplugin表示按顺序调用，但如果中间有函数返回非None时立即退出，并返回这个值
>>
>> 同时一个plugin调用点可以对应多个plugin的处理函数，是一对多的关系。这一点我在zca的例子中没有看得太清楚。
>>
>> 所以ulipad中的mixin技术不主要是为了组件的配置，更多的是为了功能的扩展，是合并，对处理，对类的扩展。如果说在ulipad中应用zca的话，要考虑：
>>
>> 如何使用zca对类进行扩展
>> 如何处理callplugin和execplugin这两种机制
>>
>
> 对unipad不熟悉，但是适配的概念，可以让程序依赖扁平话，会很少出现多层的基层，耦合降低，程序更清晰，测试起来也更方便的。
>

适配在ulipad中使用得并不多，更多的是功能的融合，所以象我所说的功能，如果zca无法实现就不适合在ulipad中使用。

> 其实熟悉设计模式的人会喜欢ZCA的。

正好我是一个不讲究设计模式的人。

>
> 看看Zope2就知道不用ZCA的问题。无数个父类，子类的功能无限膨胀，出现问题都不知道是哪里的了。

做框架与做应用程序还是有差异的，是否使用zca要看你的程序中是否需要适配这种处理。使用子类，父类一样可以实现适配。其核心不过是一种插件机制。zca只是其中一种实现而已。

[Zoom.Quiet]

2008/8/27 limodou <lim...@gmail.com>:

>> 其实，不仅仅是可替换。可重用，以及简化也是。
>> 多个相似的功能，用同一个接口抽象，对于接口的应用方，会简化很多。
>> 这个也可以用相同的父类来处理。只是需要直接进行子类的初始化，代码的耦合会大很多。
>
> interface并不负责初始化，这是用户要做的事，并不会减少。使用子类也是一样的。而是否是耦合要看你如何使用interface。我看例子中更多的是如何获取一个utility，然后使用它，因此它并不是继承的关系。而直接使用类也是一样的。在我看来interface只关心调用的接口，并不关系调用者如何。从这个意义上来说，使用类也一样。因此只是从interface角度来说，我看区别不大。
>
>>
>>> 因此我个人的理解：
>>>
>>> zca的注册，获取，配置的功能远大于interface。interface改为class也差不多，只不过interface可能有象java一样的检查功能，这一点可能要优于简单的class。但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我看到了java再现。可能对于大型的团队开发的意义要大于为了爱好而编程的小团体。
>>>
>>
>> zope的interface不严格的，不需要和实现完全一致。偷懒的话，实际上你只需要写类名就可以了。
>> 这个和java不同。
>
> 如果只写一个类名，与类更是没有区别了。更是失去了interface的意义了。
>
>>
>>> ulipad的mixin机制与zca还是不同。使用zca，你是在程序只对其进行使用，并不是对当前的类进行扩展。而ulipad的mixin是可以对某个类的属性，方法进行扩展。而ulipad中的plugin工作方式与zca差不多。整个ulipad也有类似zca的注册，获取，配置的机制。不过我还不清楚zca中的plugin机制(类似这个的机制)是如果工作的，比如在ulipad中，你在某个类中定义了一个plugin调用，然后根据调用的不同api对plugin的处理有所区别：
>>>
>>> callplugin表示按顺序调用，直到处理到最后一个，无返回值
>>> execplugin表示按顺序调用，但如果中间有函数返回非None时立即退出，并返回这个值
>>>
>>> 同时一个plugin调用点可以对应多个plugin的处理函数，是一对多的关系。这一点我在zca的例子中没有看得太清楚。
>>>
>>> 所以ulipad中的mixin技术不主要是为了组件的配置，更多的是为了功能的扩展，是合并，对处理，对类的扩展。如果说在ulipad中应用zca的话，要考虑：
>>>
>>> 如何使用zca对类进行扩展
>>> 如何处理callplugin和execplugin这两种机制
>>>
>>
>> 对unipad不熟悉，但是适配的概念，可以让程序依赖扁平话，会很少出现多层的基层，耦合降低，程序更清晰，测试起来也更方便的。
>>
>
> 适配在ulipad中使用得并不多，更多的是功能的融合，所以象我所说的功能，如果zca无法实现就不适合在ulipad中使用。
>
>> 其实熟悉设计模式的人会喜欢ZCA的。
>
> 正好我是一个不讲究设计模式的人。
>
>>
>> 看看Zope2就知道不用ZCA的问题。无数个父类，子类的功能无限膨胀，出现问题都不知道是哪里的了。
>
> 做框架与做应用程序还是有差异的，是否使用zca要看你的程序中是否需要适配这种处理。使用子类，父类一样可以实现适配。其核心不过是一种插件机制。zca只是其中一种实现而已。
>

ZCA 比 Mix-in 最大的好处就是 有JAVA的大量理论基础,
黑话,比较正统,看起来舒服些,
很多时候,俺感觉 Python 其实和 Perl 是类似的
都是
TOOWTDI

[limodou]

2008/8/27 Zoom. Quiet <zoom....@gmail.com>:

> 2008/8/27 潘俊勇 <panju...@gmail.com>:
>> 对了，其实不用ZCA一定能够解决问题。
>>
>> 比如unipad肯定有自己的一套方法。
>>
>> 但是，ZCA只是提供了一套标准的方法。
>>
>> 学会了这个，如果大家都用这个方法，就好维护了。
>>
> 是也乎,是也乎,这是关键,
> 在传教未成功前,这种机制就没有用,
> 但是使用机制来减少开发复杂度的前提又是得足够多的人理解和使用,以及不断增补,
> 又是个基础模块的自举难题,,,,
>

zca的机制是否是标准还尚未可知，但是远比ulipad的要复杂，更重要的是它是否能实现我在前面所提的功能，如果不能，再好的东西也并不适用啊。也并不是因为采用了zca就变得容易维护，zca本身还要花时间和精力还学呢。

[limodou]

> ZCA 比 Mix-in 最大的好处就是 有JAVA的大量理论基础,
> 黑话,比较正统,看起来舒服些,
> 很多时候,俺感觉 Python 其实和 Perl 是类似的
> 都是
> TOOWTDI

正统可能更适合于大型团队开发，象我这个业余份子如果是看重这点，我当初就一直学java算了。我看重的是Simple is best.

[Chen Houwu]

A）很同意limodou所说的下面：
1."但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我-看到了java再现。可
能对于大型的团队开发的意义要大于为了爱好而编程的小团体。 "
2."interface并不负责初始化，这是用户要做的事，并不会减少。"
-------
interface和class的最大的不同就是，前者不包括实现。假如多人并行开发A,B两个模块，A需要调用B，但是此时B还没实现呢，怎么办？解
决办法:
（1）A不再直接调用B，而是要使用一个接口C，然后B去实现接口C。此时，控制反转了，A不再依赖B，变为B依赖A提出的接口C。
（2）在开发时，A可以暂时使用接口C的一个Mock 实现进行测试，集成时，再用B来代替那个Mock实现
（3）很明显，那个Mock实现以后是要被B替换掉的，怎么办？用依赖注入框架可以很干净地解决。
C）潘提供的那个文档，不久前我看过，API稍有点没跟上最新的版本，不知道最近更新了没有。

On 8月27日, 下午5时11分, limodou <limo...@gmail.com> wrote:
> > 其实，不仅仅是可替换。可重用，以及简化也是。
> > 多个相似的功能，用同一个接口抽象，对于接口的应用方，会简化很多。
> > 这个也可以用相同的父类来处理。只是需要直接进行子类的初始化，代码的耦合会大很多。
>

> interface并不负责初始化，这是用户要做的事，并不会减少。使用子类也是一样的。而是否是耦合要看你如何使用interface。我看例子中更多的是如-何获取一个utility，然后使用它，因此它并不是继承的关系。而直接使用类也是一样的。在我看来interface只关心调用的接口，并不关系调用者如何。-从这个意义上来说，使用类也一样。因此只是从interface角度来说，我看区别不大。
>
>
>
> >> 因此我个人的理解：
>
> >> zca的注册，获取，配置的功能远大于interface。interface改为class也差不多，只不过interface可能有象java一样的检查功-能，这一点可能要优于简单的class。但对于小项目是否这么做就不一定了。我之所以不喜欢java主要的一点就是规矩太多，而interface这个东西让我-看到了java再现。可能对于大型的团队开发的意义要大于为了爱好而编程的小团体。

>
> > zope的interface不严格的，不需要和实现完全一致。偷懒的话，实际上你只需要写类名就可以了。
> > 这个和java不同。
>
> 如果只写一个类名，与类更是没有区别了。更是失去了interface的意义了。
>
>
>
>
>
>
>

> >> ulipad的mixin机制与zca还是不同。使用zca，你是在程序只对其进行使用，并不是对当前的类进行扩展。而ulipad的mixin是可以对某个类-的属性，方法进行扩展。而ulipad中的plugin工作方式与zca差不多。整个ulipad也有类似zca的注册，获取，配置的机制。不过我还不清楚zc-a中的plugin机制(类似这个的机制)是如果工作的，比如在ulipad中，你在某个类中定义了一个plugin调用，然后根据调用的不同api对plug-in的处理有所区别：

>
> >> callplugin表示按顺序调用，直到处理到最后一个，无返回值
> >> execplugin表示按顺序调用，但如果中间有函数返回非None时立即退出，并返回这个值
>
> >> 同时一个plugin调用点可以对应多个plugin的处理函数，是一对多的关系。这一点我在zca的例子中没有看得太清楚。
>

> >> 所以ulipad中的mixin技术不主要是为了组件的配置，更多的是为了功能的扩展，是合并，对处理，对类的扩展。如果说在ulipad中应用zca的话，要-考虑：

>
> >> 如何使用zca对类进行扩展
> >> 如何处理callplugin和execplugin这两种机制
>
> > 对unipad不熟悉，但是适配的概念，可以让程序依赖扁平话，会很少出现多层的基层，耦合降低，程序更清晰，测试起来也更方便的。
>
> 适配在ulipad中使用得并不多，更多的是功能的融合，所以象我所说的功能，如果zca无法实现就不适合在ulipad中使用。
>
> > 其实熟悉设计模式的人会喜欢ZCA的。
>
> 正好我是一个不讲究设计模式的人。
>
>
>
> > 看看Zope2就知道不用ZCA的问题。无数个父类，子类的功能无限膨胀，出现问题都不知道是哪里的了。
>

> 做框架与做应用程序还是有差异的，是否使用zca要看你的程序中是否需要适配这种处理。使用子类，父类一样可以实现适配。其核心不过是一种插件机制。zca只是-其中一种实现而已。

>
> --
> 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

[为爱而生]

2008/8/27 潘俊勇 <panju...@gmail.com>

微软有COM组件架构，使用接口来拼装应用，很牛。

大家都是架构师吧？
我看不懂大家说的。不过潘老大发的这个东东，提到COM，有点激发我的兴趣。
我一直想找个东东可以让Python不操作COM那些破东东，就可以直接像VBScript一样，在Windows平台上操作对象，比如操作EXCEL之类的，完成我想要的操作，请问ZCA能做到不？我没看你发的那个文章，先问问！

貌似我在问ZCA能不能代替COM了。晕！我自己都不知道怎么问了，各位别笑我！

对于复杂应用，组件架构大大简化了开发过程，系统更可扩展，柔性更强。

Python上是否有类似的成熟体系？

有的，twisted在用，zope在用，还有很多知名的python软件都在用....

那就是著名的Zope Component Architecture，来自于Zope社区的一个系统，却已经在整个python社区开花结果
了。。。。

发展了若干年的宝物在这里：

http://www.muthukadan.net/docs/zca.html

（绝对不是新鲜玩意了，如果您还不知道，责任不在您，只怪zope社区广告没做好）

即便你做非web的程序，这个也是试用你的，上的例子就是基于pyGTK的。

很简单的概念(适配器、工具)，却容下了各种设计模式的纷繁内容，秉承了python"大道至简"的理念。

如果你只想作python脚本级别的开发，这个您可能不那么需要ZCA；

如果您是真正的pythoner开发人员，ZCA绝对是不得不学的附加，我超强力推荐！

广告到此结束。

（如果有人想翻译上面的文章，和俺联系）

--
"OpenBookProject"-开放图书计划邮件列表
详情: http://groups.google.com/group/OpenBookProject
维基: http://wiki.woodpecker.org.cn/

[limodou]

2008/8/27 为爱而生 <boye...@gmail.com>:

>
>
> 2008/8/27 潘俊勇 <panju...@gmail.com>
>>
>> 微软有COM组件架构，使用接口来拼装应用，很牛。
>
> 大家都是架构师吧？
> 我看不懂大家说的。不过潘老大发的这个东东，提到COM，有点激发我的兴趣。
> 我一直想找个东东可以让Python不操作COM那些破东东，就可以直接像VBScript一样，在Windows平台上操作对象，比如操作EXCEL之类的，完成我想要的操作，请问ZCA能做到不？我没看你发的那个文章，先问问！
>
> 貌似我在问ZCA能不能代替COM了。晕！我自己都不知道怎么问了，各位别笑我！

ZCA不是分布式框架，它只是组件框架，是无法用来调用excel的。因此与com应该可比性不高。com是可以跨语言的，zca是不行的。

[Jiahua Huang]

On 8/27/08, limodou <lim...@gmail.com> wrote:
> 我看重的是Simple is best.
>

赞木头老前辈~

[@@]

你要的是pywin32

2008/8/27 为爱而生 <boye...@gmail.com>

[wisyou]

只要有思想没有实现不了的。组件也好。拼接也好。

快速开发也好。都只是过去别人实现的思想。

COM是一个很老的思想了，不过并没有过时，只是改变了一些形式，继续使用吧。

程序接口问题是程序员的老问题，以后也是一个问题。只要是规范总会有局限性的东西，在一个范围很好用，超出范围可能失去了意义。

你自己喜欢什么接口都可以用python去实现它的原型，很容易，也有成就感。



limodou 写道:

[fluke.l]

潘俊勇 wrote:
> 微软有COM组件架构，使用接口来拼装应用，很牛。

> 对于复杂应用，组件架构大大简化了开发过程，系统更可扩展，柔性更强。
>
> Python上是否有类似的成熟体系？
>
> 有的，twisted在用，zope在用，还有很多知名的python软件都在用....
>
> 那就是著名的Zope Component Architecture，来自于Zope社区的一个系统，却已经在整个python社区开花结果
> 了。。。。
>
> 发展了若干年的宝物在这里：
>
> http://www.muthukadan.net/docs/zca.html
>
> （绝对不是新鲜玩意了，如果您还不知道，责任不在您，只怪zope社区广告没做好）
>
> 即便你做非web的程序，这个也是试用你的，上的例子就是基于pyGTK的。
>
> 很简单的概念(适配器、工具)，却容下了各种设计模式的纷繁内容，秉承了python"大道至简"的理念。
>
> 如果你只想作python脚本级别的开发，这个您可能不那么需要ZCA；
>
> 如果您是真正的pythoner开发人员，ZCA绝对是不得不学的附加，我超强力推荐！
>
> 广告到此结束。
>
> （如果有人想翻译上面的文章，和俺联系）
>

昨天刚好看twisted代码，发现了zope的好东东，加上前辈推荐 :D 一定加大实践力度
> >
>

[YoungKing]

ZCA的感觉就是Python里的J2EE,对于企业级应用是最好不过了.如果仅仅是个人的web开发可能有些大材小用.不过里面有很多组件,选用不同的组件供自己的程序应用可以省很多事,除了著名的twisted外,zenoss也是其开发的http://www.zenoss.com/,最近还出了本书.还有著名的开源网站lanchpad也是用zope3开发的

2008/8/28 fluke.l <flu...@gmail.com>

[一哥]

感觉是和eclipse plugin在设计上有不少相似的地方.

On 8月27日, 下午1时50分, "@@" <ask...@gmail.com> wrote:
> 2008/8/27 Zoom. Quiet <zoom.qu...@gmail.com>