Zope 宣传檄文汇集 ::-- ZoomQuiet [2005-08-11 10:39:52]

Zope访谈

对话Zope 系列!

ChinaZope - Pan Jun Yong

#pragma section-numbers off 回到Zope 宣传檄文汇集 ::-- ZoomQuiet [2005-08-31 10:29:36]

潘老大是如何上了plone的船的?引发

  • 回答一部分先....

1) 还是先介绍一下我自己吧 ;-)

本科和研究生的学位其实都是机械,研究生阶段从事产品数据管理方面(PDM)的研究,这个倒和内容管理颇有接近;99年毕业到上海中兴通讯,从事过一段时间GSM软件测试工作;后来有一段时间JSP的web开发经历;再后来,也做过数据仓库方面的一些大型的开发和应用。

a. 潘兄和zope/plone 的關係(如何時開始使用, 原因等)
2:你什么时候在什么情况下知道Zope的?

我对开源一直是很感兴趣的,但是知道zope其实很无意;当时在研究工作流引擎方面的产品,先研究过offbiz等java项目,发现系统无比复杂,全部要靠配置文件操作;后来找到了openflow这个zope上的产品,后来又找到了zope;

Zope的ZMI让我耳目一新,从前JSP上如此复杂的操作、功能,在Zope上可轻松实现。然后看到Zope公司那些巨型的案例,以及zope.org上无数的产品,后来有发现CMF,这才知道:自己要做的大部分事情zope这个平台都已经替你完成了。后来看到Plone,知道有人把你最不拿手的界面问题都解决了,这个时候,我就觉定投入到这个产品中。

(补充一下,我是在开始zope编程的时候,才开始python的,limodou、杜工当时都是我崇拜的对象,现在也是)

2:你什么时候编写了什么Zope 的应用?

是最早的模块,是CJKSplitter,大概在2002年10月左右就完成了。当时发现Zope最大的障碍是不支持中文搜索。虽然台湾有人做了一个模块,但是使用配置非常麻烦,而且在windows上好像还不太能用,也不支持简体。这时候我就写了一个CJKSplitter,其实当时对Zope还根本不太熟悉
;-)

算的上一个应用的,是我们公司现在rpAnalyzer的前身,另外一个ZMI版本的分析器,用于分析一个CRM系统的数据,大约是2003年1月左右完成的吧。

3:你什么时候什么情况下知道Plone 的?

在研究CMF的时候,发现一个skin计划,顺着找过去,发现“性感”的Plone站在那里,一下子就给迷倒了;-)
当时还根本没有CMF的文档,可怜我当时的辛苦,Plone也只有0.9版本,Plone的文档也非常少。

好在我看代码的能力比较强,这都是当年在中兴测试软件的时候练出来的;-)

我先作分類 

a. 潘兄和zope/plone 的關係(如何時開始使用, 原因等)
1:你什么时候在什么情况下知道Zope的?
2:你什么时候编写了什么Zope 的应用?
3:你什么时候什么情况下知道Plone 的?

b. zope/plone 在中國的發展
9:在中国的Zope应用项目水平如何?定制深度,广度如何?
X:就你所了解的情况,有哪些公司或个人,在以商业或非商业的方式在使用zope/plone,比例分别是多少?

(潘兄建議集中於社區發展, 潤普為主的這部份可能要刪減)
c. 润普的問題
4:润普是在什么情况中决定成立的?
5:润普的启动资金是哪里来的?
8:润普的主要项目来源是什么?
10:对于润普的发展有什么计划?

d. czug 的問題
6:CZUG是在润普的什么时期创立的?
7:对于润普和CZUG 的运作有什么感想?
11:对于CZUG的发展有什么计划?
XX:CZUG是如何与社区成员互动的?除了写教程、文档、论坛交流外,再有就是翻译,有没有其它共同的开发项目?
XX:CZUG网站本身进行了大量的plone定制,为什么这一定制部分没有开源?或者说没有形成经验分享给大家?(新手总是在问重复的问题与czug的经验没有成文档的分享有关吗?)
XX:czug与zope/plone的社区是如何互动的?提交的产品或者补丁是以czug的名义,还是以你个人的名义?

e . 其他 (如果發展這社團, 和個人問題)

作为一个程序员,常有这样的心态:
  我好不容易掌握的知识,为什么要轻松的告诉别人?
  自己开发的模块,为什么要免费贡献出去?
  你怎么看这种封闭现象?


回答


扩展讨论

  • 大家可以继续抒发哦

Plone Soutions - Alexander Limi

Plone创始人Limi的采访

Contents

先翻译一段,准备陆续翻译完,limi对社区的做了非常大的贡献。他的言论,对CZUG的构建和发展也非常有好处。-- PanJunYong

问1:你是谁?

我是Alexander Limi,挪威Plone Soutions公司的首席架构和交互设计师。教育背景是心理学和计算机科学。

问2:你和Plone以及Plone项目的关系是什么?什么时候,你是如何进入Plone的?

2002年我和Alan Runyan在Texas Houston开始这个项目。我现在在项目中的角色是用户界面设计,项目管理和社区沟通协调。同时,我是Plone Solutions公司的一员,这是我的一个公司,我的朋友、一些Plone开发人员也在其中。我全职做Plone相关的工作,虽然我偶然也被雇佣去做纯粹的用户界面和交互设计。

问3:你任务Plone作为一个机会速最出色的地方是什么?

Plone在一个非常灵活的软件栈之上构建,我们可以快速地改造以满足新的一些机会,或者实现新的想法。Plone在这个过程中是很轻量级的,实现某个功能,让他成为核心框架的一部分是很容易的,只需要让其他人认同让这个组件进入系统。

另外一个主要的部分是,我们有强力的多语言支持。目前Plone支持超过50种翻译,拥有唯一的超强的处理国际化和本地化的方法,以及在多种语言中维护内容的方法。这使得我们在类似欧洲的市场中处于前列,那里多种语言的支持几乎是必要的,但同时也开始影响传统只有一种语言的市场,比如美国。西班牙语作为第二语言的兴起,让很多公司正式寻找那些能够处理超过一种语言的软件。

有趣的是,我任务Plone作为一个技术最强壮的地方是,他大部分的价值在Plone的愿景、目标和解决挑战的方式。Plone最积极的观点,实际上是技术并不那么重要,这不是因为技术而技术。如果Plone将全部底层切换为另外的什么东西,它仍然是Plone,她仍然是一个拥有强大愿景和方向的强大社区。选择这个技术,是因为她在开始最可能解决我们的问题,但是作为一个社区,我们非常灵活。我们可以调整底层技术来解决我们的问题。这是Plone和她的社区最积极的东西:她的多样性和灵活度。我坚定相信这个态度影响了这个软件和参与的人员。

问4:Plone最大的问题,或者威胁是什么?

如大多数开源项目一样,文档是一个最大的困扰。引入新的Plone开发人员应该可以变得更加流畅些,但由于相对比较大的软件栈的使用,这也更加困难。web开发是一个复杂的工作,使用web进行内容管理则更是。但,这个在去年已经进步了许多,已经出现了使用多种语言发行(英语、德语、日语)的4本书,还有更多会出现。

至于威胁,现在最大的威胁不是技术问题,而是市场和注意力的斗争。好在,我们在众多的优秀系统中脱颖而出,每次发布,人们都开始关注我们。有趣的是,现在开始看到Plone开始不断在不以Plone为中心的各种文章中出现,说Plone已经被用于X或Y,或者说是"在商业领域一个可用的系统"。尽管如此,我们在这方面还有很多事情要做。

我坚信Plone下一个大的挑战是市场 / 注意力/ 讲解 领域,这是我个人最近大量时间和精力的花费所在。

问5:你对Plone社区的感觉如何(如:强/弱、紧密/分散,大/小,等)?在Plone的开发中,社区的重要性如何?

Plone社区现在达到了非常多人的阶段。这表示,既便他的某些领导者一段时间不太参与,这个项目也不会停滞;而且,现在有足够多的公司完全依托Plone来做生意,不管某些人或者公司出现什么问题,他们都需要让这个项目保持活跃。

问6:你感觉是社区的一部分吗?社区对你自己对Plone的行为影响多大。

社区很影响我的行为。不断的反馈,过滤和监视Plone用户和开发人员邮件列表,对推进Plone和解决人们实际面临的问题和挑战非常重要。这个社区是Plone。

问7:Plone从一开始就已经是开放源代码了,当时是如何做出这个决定的?

这是理想主义和商业敏感的一个融合。我们都相信软件是一个商品,它也可能变成负资产。也就是说如果人们没法继续贡献,最终它就一钱不值。软件需要不断的构建和优化框架来解决你的新调整,你需要人解决这些问题,来帮助你走出困境。一旦某个公司破产,他们的软件就消失了,因为他是封闭源代码的和私有的。真正的价值来自对产品的优化、不断的测试和改进,这些能够再次帮你的客户解决问题。这是价值链中非常重要的一环。如果软件带来的问题比它解决的还要多,它就不好了;对于自主版权的软件总是很容易陷入前面的这种类型,尤其是对于这类软件来说。

从商业角度来说,这也是唯一可以接受的方式。一小群人,凭借自己的力量,完全没有办法和你那些类似Vignette, Interwoven or Documentum 的庞然大物作战。因此,你使用开放源代码做为一个竞争优势。对于公司中使用的内容管理系统这样关键的东西,开放系统是唯一的长期可行的解决方案;

内容管理系统的市场天生就是机能不全的:当你从供应商那里作为一个自主版权的产品,你才仅仅走了一半。你需要和你自己的现有系统、你的工作流、你的业务过程进行集成。你为什么要为这个仅仅一个公司才能做的特权支付?如果你的供应商改变了业务方向,或者破产,将会发生什么情况?你还能让你的系统正常运行吗?你还能扩展它,让它和你不断变化的业务适应吗?

问8:使用Plone构建他们的解决方案,是类似Plone Solutions这样公司的特殊商业模式中明确的一部分吗?

其实更多是另外一方面 (原文:It was more the other way around ) - Plone Solutions是基于兼容软件开放源代码途径的商业模式构建,而且基于相同的核心价值构建。这就是说,Plone社区真正漂亮的东西是:他非常关注商业。大多数严肃的Plone开发人员来自全职开发Plone的公司,并以之为主要的、或者甚至唯一的收入来源。想法,也有很多开发人员,他们是纯学术的或者是学生,他们是整个Plone生态中扮演重要的角色。他们通常有很多有趣的想法,而且有时间来实现他们。

我相信,商业和理想主义的这个结合,能够让Plone社区成功 - 他们在不同的方向一起拉动,但是因为只需进行必要的沟通和协调就可满足双方的的需求,你可以得到一个非常柔性和强大的、有众多竞争力的工具。

How much of a help or hindrance is Plone's license when you sell Plone-based solutions?

问9:当你出售基于Plone的解决方案的时候,Plone的许可证有多大的帮助或者障碍?

对我们自己,而不是所有人,这决定于你所在的市场 - 有些市场(比如欧洲)对开放源代码非常接受,其他的市场(比如美国的)则更多是怀疑的,需要更多的说服工作。当然,这是一般的情况,会有很多具体的商业因素。比如:航空工业对开放源代码会更严格,但政府会更加接受。我们非常幸运,我们总能获得比我们想做的更多的工作机会,而且能够高兴的找到有趣和有益的客户,他们帮助构建Plone和他的内部结构,而不是为了生存而对我们的理想进行妥协。

Many would consider the team of "limi & runyaga" Plone's spiritual leaders, if you will. Yet, while you have been very active and vocal on the mailing lists and chat room, Alan has been quite silent, both on the lists and in the codebase in the time leading up to the 2.1 release. Do you agree with this assessment? Do you feel that there is a leadership vacuum on the technical side, or is the community sufficiently strong to manage by itself?

问10:很多人认为,"limi &runyaga"是社区的精神领袖。然而,当你非常活跃,在邮件列表和聊天室经常发言的时候,Alan无论是在邮件列表、还是在发布2.1版的代码库中,通常非常安静。你同意这个说法吗?你是否觉得在技术方面有一个领导真空,或者社区是否强壮到有能力自我管理?

真空有时候是有益的:你在专注平衡一方的时候,不会被其他因素影响。尤其是,接下来的这个版本已经看到,大量的和重要的更新是和用户使用习惯相关的,尤其是你在你坐下来第一次开始使用Plone的时候;他给我们时间来优化和重写一些核心组件,而不是不断发明新的内部结构 - 这对作为一个产品的Plone非常重要。

当然,你不可能永远处于那个状态,我们有明确的认识:技术和用户界面两方面相同重要。社区认识到了这个,在一定程度上(当另一方实现很多时)能够自我修复。如果技术方开始落后很多,社区就会开始提出问题。如果技术,我们会选择某人来领导技术决策。幸运的是,我们不必到这个程度才开始做这些,你可很容易看到社区的这个自修复机制正在工作。

我预计Plone最近将进入更多功能扩展和内部优化的阶段 新一代的优化界面需求已经开始驱动内部结构的提升了。当前的阶段修改了很多用户界面的基础问题,我们准备开始进入下一个功能级别,一起来将优化用户体验,以和新增加的强大功能相匹配。

有趣的是,既便增加功能和优化结构上耗费了大量资源,我们还是很奢侈:我们能够让很多没有实现的可能可通过底层的细小优化和一些用户界面工作而不被锁定。用户界面方面最重要的事情是:优化、优化、优化。总是有很多事情可以做得更好,大多数情况下演变比革命要更好-既便通常后者要来得更诱人。

回到最初的问题,我完全相信社区达到必要时能自我组织的阶段。在这条线上,有足够的资金和商业机会,他能够让公司在这个开发过程中开始投入资金。当然,人民希望原始的团队领导能够提供远景和指导,但他们不再需要做所有的工作,象他们从前那样。

我主要看到我现在的角色是提供远景和组织社区,以拉向某个方向。通常很难脱离实际的开放工作,因为有时候这个需要什么的远景已经非常细和明确了,以至于诱使你自己正确完成他。将工作委托给其他人来说,是社区成长的一部分,我坚定相信Plone正在朝这个方面正确迁移。这个过程很痛苦,但是最终会受益颇丰。

问11:领导Plone社区、回答邮件、解决争论的时候,你的主动性积极性如何?做这些事情的重要性如何?该谁来负责?

答:我现在非常活跃... 社区是我们最重要的财富:现在社区拥有这么多的牛人,为Plone做了那么多难以置信的事情,但是当初只是一小群人。

更多的人应该参与进来。但目前我很难保持沉默。一个人不可能参与各方各面。我想,作为一个社区,一个团队单元,这类似婴儿的成长,逐步的放开让他自己去走。让他自己去认识各种事情。

和其他社区不同的是,Plone社区有非常多的面对面交流机会。我们组织工作室、会议和非正式的聚会,大多数人在社区拥有很多亲密的朋友。通过这个途径,我们可以对Plone相关的东西进行非常深度的讨论,而且很少出现不愉快,因为他们很有可能彼此相互见面,然后知道他是一个人,一个不错的家伙。这是将"在讨论什么"与"谁在参与"的一个不错分离,而且这促就了一个健康的社区。我们能够成为生活中的好朋友,而且能够在具体的实现细节上兴奋的争论,同时,我们不会冒犯任何人。

问12:你对Plone社区的构成有何感想?商业驱动占多少,志愿者驱动又占多少?是否某个更加重要?公司的兴趣和志愿者的兴趣,二者是否能和谐统一?

这是一个很漂亮的、平滑的分裂。Plone拥有非常强的商业兴趣,但有同样强的志愿者工作。前面说过,这个结合构成了Plone社区,者也是Plone能够成功,但其他很多项目失败了的原因。我们从不在某个方向走太远,我们专注,但同时在无数的方向。我们在专业领域拥有惊人数量的知识,我们拥有众多通才和架构师。这是非常健康的构成,而且我们社区拥有健康的对话。

问13:很多开源项目在核心拥有非常大的理想主义,比如相信软件一个免费和共享。Plone是否完全被这些意识形态影响,或者Plone的哲学理念更实际?

好,我们回到社区的健康分裂。参与的人,包括很多理想主义者,以及很多关注商业的人。对这些问题有一个很有趣的途径,我们必须在决策的时候保证双方都能够接受。很多人以Plone谋生,其他则以之为乐趣。总的来说,我相信我们属于更新、更成熟、和兼容商业的开发源代码。我们不害怕商业和使用我们的产品赚钱。但同时,在这个过程中,我们保留一些核心价值,既便他可能让我们失去一两个合同,但是我们回家睡觉醒来的时候,我们会对自己以及我们每天做的工作感觉良好。

就这些了。把握你自己的命运,用自我满足的方式工作,一个可靠的产品,而且非常多有趣的、让人惊奇的人。


扩展讨论

  • 大家可以继续抒发哦

Zope CTO - Jim Fulton

Jim Fulton(Zope公司首席技术官)访谈录 Document Actions

回到Zope 宣传檄文汇集::-- ZoomQuiet [2005-08-25 03:09:17]

0.1. Jim Fulton

这是Zopera team做的Jim Fulton的访谈。问题是从Zope的法语社区收集的。Jim回答了Zope的起源和未来,还有Zope公司和Zope的商业模式。
Jim Fulton(Zope公司首席技术官)访谈录
  • 原作:Publié le 15/02/2002 par
  • 翻译:alang,于2005/08/25
  • 来源:http://www.zopera.org/Members/odeckmyn/fulton_iv_2002/view

    1. Zopera Team (ZT) : 你是什么时候发现Python的 ?
      • Jim Fulton (JF) : 1994
    2. ZT : 你什么时候决定要使用它?
      • JF : 1994.那时我正在为Rand公司的Walter Hobbs用Per实现的一个/rdb数据库而工作。它有一个基于Perl的、使用Perl解释器的数据库操纵语言。我努力的让它可以为美国地质勘探局/ 美国地理学会?(USGS,US Geological Survey)的科学们工作。那些人觉得Perl的语法太怪异了,并且Perl的自动把字符串当作一个数字的问题,给数据分析带来了许多麻烦。我正在寻找 一个轻量级的、面向对象的语言,让我可以操纵数据。我找到了Python。 
    3. ZT : 你是什么时候决定增强/升级它的?(我们的google狂人们只找到了至1994年之后的信息)
      • JF :我猜第一次真正的增强,是虚对象API(abstract-object API),是我和Guido在1995年做的。我写了一个Python扩展来访问Ingres数据库,并且正在开始做一个工具,它能自动生成访问 Fortran库函数的(Python)扩展。Python的C API非常cool,但是用它,让写一个非常灵活的给它传递数据的扩展的工作变得太难了。
    4. ZT : 这听起来好象你曾经做过SmallTalk程序员?(Smalltalk,一种“古老”的面象对象语言--alang注)

      • JF :是的,Smalltalk太cool了。我用GNU Smalltalk给USGS的家伙们写了一个可视化的图表编辑器。我另外花了一点时间在ANSI Smalltalk委员会上。那儿似乎到现在还有一些有条不紊的工作在进行,尤其是Squeak。(Squeak是Xerox PARC实验室的Alan Kay大牛人--可惜今年被HP给裁员了--发起的一个基于新的Smalltalk-80标准的一个开放源码的新的语言。alang注)
    5. ZT :那时让你有了这个想法,用SamllTalk来写Zope。是真的吗?

      • JM : No. :)

    6. ZT : 为什么你最终选择了Python?
      • JM : 那个时候我已经成了Python的皈依者了。 ;)

    7. ZT :如果今天再来让你选择,你会选择Python,或者会试着用SmaallTalk(用squeak或者GNU SmallTalk)吗?

      • JF :我很确信,我还是会选择Python。有很多理由:
        • Python的语法更清晰易懂
        • 多重继承。当有多重继承的时候,它会使多个框架的协同工作更简便,途径更多。
          • 这儿还有许多其它的理由,在1996年的时候我就考虑不再使用Smalltlk了,例如Smalltalk的实现缺乏可移植性,或者对非 GUI应用支持很差。我真的没有再继续用Smalltalk了。Squeak非常有趣,Smalltalk的社区可能在其它的方面有了许多进展吧。 我非常确信,Python可以从Smalltalk学习不少东西。我尽我的一些努力吧。

0.1.1. Zope公司

  1. ZT : 你是什么时候认识Paul Everitt的?
    • JF :我和他是在第一个Pytho研讨会上认识到的,通过邮件。我们通过Python的一些活动保持联系。
  2. ZT :那就是你决定加入Digicool adventure 的原因(Digicool adventure,Zope的前身--alang注)
    • JF :咳,那时我正为USGS工作。USGS是一个非常棒的组织,但是多方面的原因,让我决定了要做一些不一样的事。Boy,就是Digital Creations different。8v]
  3. ZT :现在Zope公司有多少雇员?
    • JF : 27个,大部分是工程师(这个访谈是2002年做的所以这是2002年的数字。alang注)。
  4. ZT : 他们中有多少人为Zope内核工作?
    • JF : 所有的人.
  5. ZT : 他们中有多少人为你们的直接客户作顾问工作?
    • JF : 所有的人.
      • 我说的是真的,完善一个工具最好的方法就是去实际用它。当然,并不是我们为客户所做的每一件事都会放入Zope内核里面。但是我们通常为了让用户更好的使用Zope而改进我们的Zope内核。
  6. ZT: 一天之中他们必须有多少小时来膜拜你 ;-) ?

    • JF : 我希望没有.

0.1.2. Zope的商业模式

  1. ZT :这么多来年以来,你有没有一个对web开发之未来的展望?或者你试图尊从工业标准并且做到最好吗?
    • JF : 我是一个面向对象的狂热者,Zope一直借助于面向对象技术和Python的力量,让构造复杂的Web应用更加的简单。
      • 我们当然要尊从工业标准。我们一直着重强调那些我们的客户需要的或者能让我们的生活更轻松的标准。同样的,对于Zope社区也是必须的。
  2. ZT :我们听说Zope公司在运作上取得了进步,要得益于为用户(ZOracleDA)作的开发工作。但是,作为一个CTO,相比于在客户需求方面取得进步,更令人沮丧的应该是没有能力在规划优先级和资源的idea方面取得进步。
    • JF :那的确是令人沮丧的,是的。在一个孤立无援的环境里面开发软件,总是会让人沮丧的。幸运的是的,当Zope公司和Zope的社区碰到一起时,会产生很大的创造力去完善产品,有时还能预见客户的需求。
      • 在解决许多用户的个体问题时,作为Content Management Framework (CMF)的大量好主意出现了。我认为这个比以前的许多Portal Toolkit的成就都要成功的多,部分原因是因为它是被特殊用户需求驱动的。CMF是外面咨询项目的基石。
  3. ZT :这看起来更像是一个顾问型的公司在改造它的没有先进idea的软件,而不是一个软件型的公司,是吗?你们开源了这个项目以弥补这个不足吗?
    • JF :No. No.
      • 我们的咨询业务是围饶着Zope开展的,而不是其它的方面。Zope是一个为我们的客户提供实实在在好处的平台,并且让我们能花比其它方法更少的时间来构 建个性化的解决方案。Zope开源化是增强这个平台的最好的方法,接着,增强我们的咨询业务。
  4. ZT:当符合需求时,你会使用社区开发的组件吗?

    • JF : 是的.
  5. ZT :你的客户是如何看待这一点的?
    • JF : 他们意识到,重用能降低成本和风险。
  6. ZT :会有一些你为用户定制的永远也不开源的组件吗?
    • JF : 当然有.有一些组件对用户是非常特殊的,可能包含了客户专有的技术和思想在里面。
      • 有时,我们也开发一些技术,不开源,但是会与我们的客户和测试者分享它们的源码。

0.1.3. Zope的未来(Zope3)

  1. ZT :说说ZMI里面的I18N怎么样 ?
    • JF :Zope3将会内置I18n。所有的Zope3的核心代码都将是国际化的。
  2. ZT :你觉得J2ee和Zope比有哪些相通之处?
    • JF :Zope在某种程度上,已经可以和J2ee互操作。我们已经具有了通过共享Oracle数据库的方式和BEA集成的经验。
      • 当Jython2.2可用的时候,我希望会有一个社区致力于把Zope3移到到Jython/Java上。当有了可以在Jython上运行的Zope,会 出现大量的与主要的J2EE集成的机会。 我们已经开始至力于和外部调度管理器(external transaction managers)的集成,这让我们能够使它与J2EE的程序并行执行。
      • 另外一个和J2EE集成的可能性是通过CORBA.不幸的是,J2EE要求CORBA传值调用(call-by-value),这在Python的 CORBA绑定中缺少这一点(做不到)。近来的开源项目fnorb可能会弥补这个问题。
  3. ZT :Zope可以扮演一个SOAP服务器的角色吗?
  4. ZT :Zope和XML:计划是什么?Zope准备在将来扮演一个XML的海量数据服务器的角色吗?XSLT, XPATH, XQUERY这些w3c标准在Zope上实现的怎么样了?(2002年前后,是XML大红大紫的时候,那时言必称XML--alang注)
    • JF :Zope社区在一般的XML技术上已经处于领先地位了。有许多有趣的工作正在进行中,包括XML的管理,支持象RDF, XSLT and XPATH这些标准等。
  5. ZT :什么时候我们会在Zope内部有一个查询语言,比如叫OQL?
    • JF :咳,我们现在已经有了Python和catalog query languages了。这能满足大部分的需求。
      • Stephan Richter现在正在ZOQL项目上工作,目的是为Zope寻求提供一个类SQL语句的、对象操纵的语言。这对ad-hoc处理将是极好的东西。
  6. ZT : 你们Zope3的时间表是什么?
    • JF :Zope3将需要社区大量的努力,所以我不能许诺任何事情。当然,我是非常希望这个夏天Zope3就能用了。(2004年才出来,2002年时作此希望显然太乐观了--alang注)
  7. ZT :你认为Zope3最让人兴奋的特性是什么?
    • JF :太多了。太难挑选了。先列举一些吧:
      • 组件架构和新的开发模式
      • CMF的集成
      • 集成的I18n支持
      • 配置与代码的分离
      • 新的cataloging和meta-data模块 还有许多,但必须得说,最让我激动的是全新的组件架构。 (全文完)


扩展讨论

  • 大家可以继续抒发哦

为什么要选择Zope 3 (译文)

回到Zope 宣传檄文汇集::-- ZoomQuiet [2005-08-28 12:28:31]

为什么要选择Zope 3

#原著:Jim Fulton(CTO of Zope Corporation)
#来源:http://www.zopemag.com/Issue010/Section_Articles/article_WhyZope3.html
#翻译:alang 2005/08/28  (alang.yl # gmail.com)
- - - - - - - - - - - -
By Jim Fulton  | February 12, 2005

0.2. 介绍

Zope3 的第一版在11月7日(2004年)发布了。这是Zope3项目史上的一个重大里程碑。或许很多人都想知道如果他们将要使用Zope3话,到底对他们意味着什么,以及"为什么要选择它"?需要吗?不需要吗...我将试图回答这个问题,或者至少,我提供足够多的信息,让人们自己来回答这个问题。

首先,我将追思Zope3的历史,讲述它一路走来的原由。

0.3. 历史:Zope和前身

Zope最初是设计给非技术用户使用的,让他们很容易就能管理信息,创建动态的web应用。有几种途经可以达到这个目的,比如:

  • 一个通过Web来管理数据、模板和脚本的环境
  • 提供SQL方法和数据库连接,让它可以很easy的使用关系数据
  • 一个内嵌的索引机制,让它可以很easy的提供搜索功能
  • 获取机制,提供一个简单的方法可以从层层目录中共享信息;还有
  • ZClasses,提供一个基本的方法,来创建新的content类型,并且/或者扩展已有的content类型以提供新的方法或者模板

上面的这些方法,对于大多数的web应用来说工作得非常好了。实际上,有一些老土的、非技术人员开发的内容管理系统(content-management systems),仅仅使用了我说的第一个方法。

0.3.1. 使用Python给Zope带来的变化

然而,许多开发者并不满足于一个只是预先写好对象、通过web来定制的工具。对于这些开发者来说,必须有一整套开发工具和APIs的集合提供才行。比如他们才能构建额外的文件系统库,使用Python灵活的APIs。

对于Zope2的Python开发者们来说,已经有了一些显著的变化:

  • 1.Zope2这个framework非常复杂,这在很大程度上应归咎于应用领域的固有复杂性。Zope有许多特性,涵盖了从事务管理、安全性到标准元数据等方方面面。新Zope应用通常需要所有这些功能都协同工作。继承机制通常用来管理复杂事物,但是延伸的范围并不广。为了只提供最基本的功能,一个名叫 SimpleItem的类被提出来了。这个名字提醒人们,一个对象只需要提供最基本的功能就行了,而不要做过多额外的事,尽管这个基本类本身还有许多基类。这些基类为了方法的重载或者提供配置数据等不同的目的而被定制得专用化了。搞清楚哪些是要被重载的,哪些是要配置的,以及这些繁多的基类如何互相调用,这工作太难了。(真的是不可能的任务)

  • 为了尽可能简单的提供丰富的功能(特别是对于非技术用户而言),Zope做了许多自动化的工作。这对于简单的应用是非常好的,但是对于那些更复杂些的应用,反而是一种障碍了。主要表现在以下方面:
    • 隐式获取(implicit acquisition); 还有
    • 文档模板标记语言(Document Template Markup Language ,DTML)所用的名字空间堆栈
    • 利用这些便利性,用户可以不必严格的写明到哪里查找就能获得数据。大多数情况下这工作得很好,但是如果出现不可预料的命名冲突,它就很难查明相冲突的名字在哪里。就算它能运行,也很难说清楚它为什么能运行。
    • 3.Zope提供了一种非常方便的安装第三方产品(products)的机制。不幸的是,它很难适用于所有的产品。在传统的Zope产品中,一个对象的所有功能都是它自己的类或者基类提供的。改变这些产品行为的唯一方式,是去修改或者子类化它们。修改产品并不是一个好主意,因为这让维护升级变得很困难。子类化也是令人讨厌的,因为它会让基类和子类之间耦合性得过于紧密了。(这就是众所周知的脆弱的基类问题。)Zope的CMF(Content- Management Framework)的一个最大的贡献在于它的工作机制,它能把呈现和业务逻辑分离,能与目标类无关的进行管理,并且可以很容易的实现用户化/定制。换句话说,这可以让呈现和业务逻辑在不修改源码和不使用继承的情况下就能被用户化/定制。

在2000年的晚些时候,Zope公司的工程师们想出了能让Zope更好的为开发人员服务的方法。主要是以下几个方面。

  • 建立一个更好的模板系统,让开发者和网页设计师们能更容易的协同工作。在那个时候,Zope只有一个叫DTML的模板语言。DTML有一个大多数模板系统都会有的问题,那就是模板本身不是合法的web页面,不能用HTML编辑工具来编辑更新。一个设计师可以先做一个网页,但是在程序员插入代码让它变成动态页面后,它就失去控制了。我们工作的结果是设计出了一个更好的模板系统——ZPT(Zope Page Templates),已经在2002年发布了。
  • 提供一个组件模型,让定制产品更容易。意思就是说,要把产品功能分解成更精练的、可以单独升级的零部件。
  • 用一些像传统model-view-controller (MVC)或是文档视图(document-view)的架构,让呈现与业务逻辑完全的分离。

Python就是Zope的"秘密武器"。Zope正与市场上的众多基于Java的方案在竞争。为什么相比于基于Java的应用服务器,用Zope开发应用更具生产力?主要原因就是因为我们有Python。尽管有上面的这些吹捧(牛B),然而对于Python程序员来说,Zope并没有太多的吸引力。(说的的确是实情。Jim还是有自知之明的。译注) 为了让Zope对Python程序员产生更大的魅惑,为了让我们更好的撬动Python的力量,这就是我们开发Zope3的最大的原因所在。

0.3.2. 接下来的历史

在经历了几次头脑风暴之后不久(或许与之并无关联),Zope公司雇佣了核心的Python开发团队,Python Labs,他们带来了新的敏锐的洞察力。(请读者们回想一下Guido是什么时候在Zope公司呆过?译注)

正如上面提到的,那些头脑风暴的一个早期成果就是ZPT了。它让开发者和(网页)设计者的协同工作成为了可能。

我们意识到,一个类MVC的framework是需要一个组件架构的,于是我们研究了一下,它(的功能之一)应该支持业务逻辑和呈现的分离。

在一个无状态的环境比如HTTP里面,使用组件架构是一个大的挑战。在无状态环境下,每一次request所需要的组件都要被装配,这意味着组件装配必须要很容易的就能进行。

请注意CMF也提供了一些组件系统的特点。业务代码已经被从内容对象中分离了,并且分成了tools和skins。Tools是提供特定业务功能的组件。 Skins是提供呈现和业务分离的,重点在呈现上。虽然CMF能满足我们的一些需求,并且也示范了把业务逻辑和呈现从数据管理中分离的一些好处,但是我们还想看看,我们能不能把事情做得更好。具体的来讲,我们想要用对象来扩展功能,而不是用一个个的模板和脚本。CMF依赖获取机制(acquisition),这意味着所有的模板和脚本都共享着一个共同的命名空间(namespace),而不管内容的类型是什么。名字最好要包含类型信息,并且要小心谨慎的取(要不然就可能重名)。

我们考虑了一个初步的组件分类,分成内容,视图和业务组件,大至对应着MVC。还设计了一个通过注册和横切(traversal)组件的方法来进行组件装配的机制(component-assembly mechanism)。组件装配基于对象的连结,通过接口(interfaces)。

我们创建了最初的原型,让组件装配的想法能够付渚实施。这给未来的工作激发了足够强的希望。

在早期原型工作之后,我们编出了关于组件如何工作的更详细的故事,设立了一个简短的培训课程,用幻灯片来演示组件处理的流程。这个演讲是虚构的,描述了还没有写出来的软件(的工作机制)。Python Labs团队就埋头至力于定出开发流程(应该指的是详细设计。译者注),并且提供反馈/建议。我把这个演讲进行了许多次,不断根据反馈来更新我的培训课程。实际上,这个培训课程已经成了组件架构的第二个原型了。

在做详细设计的过程中,确定了一个主要的目的(超越了组件开发),要提供一个可以吸引Python程序员们的开发模式。Zope 2的Python产品有太多的Zope特有的配置信息混杂在其中,这让这些python代码拒人于千里之外,既难读又难懂。

在作这种努力的过程中,我们觉得可以通过确立Zope将会是什么样的公开的想法/思路,来极好的改善开发体验。我们决定把Zope3用为Zope的一个主要版本来推进。

在2001年将要结束的时候,我们在tutorial中不断的重申,明确要从事的Zope3项目要达到下面这些目标:

  • 改善开发体验,提供一个更合理的开发模式,吸引Python和其它的开发者
  • 让在Zope中创建有用的对象更简单
    • o让使用现存的Python类成为可能(作最少的或者不作修改) o要使用Zope的功能,只要作少量的额外改变
  • 让学习曲线变得平滑
  • 让软件重用更加便利
    • o 使用已存在的非Zope特色的对象 o 增加、删除、替换现有对象的功能 o 改变现有对象的用户接口 o 提供可替换的访问对象的方式(比如FTP,XML-RPC,wxWindows)
  • 配置Zope软件更灵活
  • 借鉴那些从使用、开发Zope2积累的经验教训
  • 把CMF的技术和开发模式整合到Zope中去

Tres Seaver在Zope公司内部已经鼓吹了很长时间的极限编程(Extreme Programming ,XP)了。在我们需要着手Zope3的实现工作时,我决定同时也偿试一下XP。我们制定了一个为期3天的开发活动,我把它叫做"sprint"(请参看 ZopeMag的Zope Sprinting指南来了解相关情况。原编辑注),尽可能用最快速度创建一个最小的Zope3的原型。我们使用了结对编程(pair- programming),故事/情景板,单元测试。这个活动证明了这时的生产力是极高的。

我们在Zope公司还举行了其它的一些Sprint活动,学习一直在进行,也得到了许多重要的早期进步。

Zope3最初是作为Zope2的一个分支开始的。我们很快意识到,已有Zope2代码的桎梏让人很难爆出新思想的火花。向后兼容老的代码,让人分心不少。最后我们决定,在一开始不考虑向后兼容的问题,很快地我们就为Zope3建立了一个独立的开发树。

0.4. 开放的进程

在2001年12月,在开放Zope仓库来捐献给Zope公司外部的过程中,我们对Zope社区公开了Zope3项目。Zope3提供了一个重大的机会,让人人能参与到Zope的过程中来。我们推广了sprint,在Fredericksburg举行了三次python sprints,分别在2002年的一月和二月。

  • 使人们加入到Zope3的开发中来
  • 建设这个社区;还有
  • 完成重要的工作

sprint活动最重要的好处是让人们能碰个面,互相认识,还有相互合作。这让后来的远程工作变得更容易了。

Zope3项目也导致了为Zope工作的人数大量增长。主要的和大多数的代码都来自Zope公司之外的贡献。Zope3是个名副其实的社区项目。

0.5. 发现之旅

从Zope3项目宣布到现在,已经整整3年了,这比预期的长了许多。大多数功能是在第一年开发出来的,那时进展神速,并且是在没有任何Zope2代码的基础上,只是从一个广阔的社区中得来的。在2002年底,我们开发出了我们认为应该是第一个alpha版的release。

在2003年初,我们进行了一连串的"geddons",这是一个为了及时的在夏天完成Zope3所进行的重构工作。这是评估我们工作成果的一段时期。然而基于我们的经验,我们发现原始设计方面需要修改。到2003年的秋天,我们已经作了许多重大的改进,但是又确信还有许多修改要做,一直要进行到2004 年。

从2003年初到2004年是一个巩固基石的时期。只增加了为数不多的新功能。工作重心几乎全部放在建造一个可供日后增添功能的稳固的基石上。大致可以描述为--简化框架!后期增加的代码大部分又去掉了。

许多修改是十分有意义的。举例来说,我们停止使用上下文包装(context wrappers)来指明对象的位置(location),换为了直接保存位置路径,这使得位置感知(location-aware)和对象引用的代码被大大简化了。我们完全重写了大部分的子系统,这些修改极大的完善了最终系统的结构。这些是可行的,因为我们希望花些时间,来从最初的失误和重做工作中得到一些教训。

作出要慢下来并且要从容不迫、花费双倍的时间来做出第一个发行版的决定,是基于我们要求卓越的承诺,还有,意识到了我们不必那么操之过急。因为不管怎么样,Zope2还是一个优秀的系统,它还有很长的生命周期呢。

在Zope3的工作中,我们的开发流程也改进了。我们做到了:

  • 养成了测试的习惯
  • 养成了一个优秀的文化:为了让事情做到最好试着把步伐慢下来,如果有必有情愿把工作重新来过;还有
  • 创立了一个新的方法来试着把文档和测试结合起来,这很快成了一个非常积极的习惯。

0.6. X3.0的发布

到2004年初,已经有了好几个使用Zope3的产品了。很明显的,Zope3已经为产品应用作好了准备,虽然还缺乏几个功能或者还没有准备好要发布。一些本可以在产品中很技巧性的使用Zope3的人,不愿在他们所需要的功能没有稳定之前冒险这样做。我们决定缩小第一个release的目标,只包含那些已经稳定的基本功能,能让那些不需要传统的通过web在线开发(through-the-web development)功能的人开始使用Zope3。我们给Zope X3.0定位于开发人员发行版,只包含那些从2004年初夏起就已经稳定的功能。

0.7. Five项目

最近有个开发项目Five(http://codespeak.net/z3/five/),可以在Zope2中使用Zope3的组件架构,来提供部分的Zope3的功能。

现在的Zope3还不向后兼容Zope2,虽然有Five项目的一些努力,但是许多Zope3的功能都不能用于Zope2.

现在的Zope3是给Python开发者们用的。还没有对web在线开发的功能提供稳定的支持,尽管已经有了简单的试验版。我觉得一段时间之后就不成问题了。

有许多Zope3的第三方产品,部分已经在Zope2中成熟稳定了,象cataloging,已经包含于Zope3中了。

基于上面这些有限的信息,Zope3给你展现了一些显著的优势:

  • 它提供了一个非常清晰的开发模式。试用过Zope3的开发者们都会发现它是一个比Zope2更具生产力的开发环境
  • Zope 3更容易适应特殊的业务需求。有趣的是Zope3应用再也不像传统的Zope应用了。举例来说,一个应用不再需要使用传统的"对象文件"模式,Zope3让那些使用关系数据库的应用变得简单得多
  • Zope3被设计为从底层支持I18n 和 L10n应用
  • Zope3提供了很好的文档:一本书(还在不断增加中),一个教程,一个内嵌的Api参考手册,和一个在不断细化的内部开发文档。

== 你该使用Zope3吗?==

Zope 3 既有重大的改进,也有相对于Zope2的局限性。是否需要使用它依赖于你的实际情况。幸运的是你不必马上转换到Zope3上面。Zope2还将伴随我们相当长的时间。实际上,Zope2可以让我们从容不迫的对待Zope3。要感谢Five项目,你可以在Zope2的应用里面使用部分的Zope3技术。随着时间的过去,Zope2也会具有更多的Zope3特性,让最后转变到Zope3的结局更简单更容易。

(全文完)(不含空格11269个字)

web应用服务器的新星 - Zope

web应用服务器的新星 - Zope

回到Zope 宣传檄文汇集::-- ZoomQuiet [2005-08-31 13:59:08]

作者:潘俊勇
鸣谢:感谢limodou, nEO, arthur, blueszhao, zoomq, backrain, Tomz等CZUG成员提供修改意见

如果你是一个Python语言的爱好者,那你应该知道Zope这个Python上的杀手级软件;如果你阅读过Eric Raymond的著名的开源启蒙文章《魔法大熔炉》,那你应该知道Zope这个经典的开源商业化案例;如果已经厌倦了J2EE的繁琐,或者Ruby On Rails的过于简单,那么,Zope应该是值得你关注的另外一个选择了。

Zope(www.zope.org)是一个开放源代码的web应用服务器。2002年,Zope被Linux Journal评为最佳的web应用服务器;2004年,Zope成为冠群CA公司宣布其开放源代码战略后的首批资助项目;Zope拥有美国海军、北约组织、美洲银行、波士顿在线、法国10多个政府部门、摩托罗拉、SGI等众多的重量级用户。

使用Zope,可快速构建功能强大、可扩展的web应用。典型的,比如内容管理、内部网、电子商务、门户,甚至ERP应用。其中,世界级的内容管理系统Plone便是基于Zope构建。Zope上有丰富的第三方产品插件供选用。

1996年,当时是Zope公司CTO和 Python领袖的Jim Fulton,为教授CGI程序起草讲稿。Jim针对这门课程,以他自己的方式研究了所有关于CGI方面的现存文档。在讲课返回的途中,Jim开始思考传统的CGI的编程环境中他不喜欢的方面,包括:脆弱、缺乏面向对象和暴露Web服务器细节等。从这些最初的沉思开始,在返回的飞机中Jim写出了Zope的核心内容。

Zope主要使用Python语言编写,在涉及的系统性能地方则使用C语言,可在Windows、Linux、Unix、Mac OS等多种平台上安装运行。它自带一个面向对象的数据库ZODB,所有对象均可保存在这个对象数据库中,通过Zope页面模板(ZPT)编写动态页面展现对象,Zope服务器则用于发布对象。

事实上,ZOPE就是Z对象发布环境的简写(Z Object Publishing Environment)。用户可通过http、ftp、xml-rpc或webdav等途径发起请求,Zope自动将请求封装为一个统一的 REQUEST对象,根据URL进行对象漫游、定位,将参数解析、预处理、传递到对象的方法并执行,最终返回执行结果。这个过程中,Zope负责调度从 URL到对象方法执行的整个过程,大大简化了开发的工作量,实现了完全面向对象的开发。另外,在对象发布的过程中,Zope能够根据对象实例的包容关系,获取父对象的属性,从而实现了实例的继承。

面向对象数据库系统ZODB是Zope的另外一个重要的特性。ZODB实现了对象的透明存取,开发人员不必关心对象的存取细节;ZODB支持事务处理,能够用于企业关键应用;ZODB支持自动的对象缓存管理,能够调节和优化性能;最重要的,ZODB支持ZEO(Z Enterprise Object),可将对象分布在多个Zope实例上并行运行并保持同步,这使得Zope能够支持多机负载均衡,可平滑扩展,用于大型的应用。

Zope内置了精细的用户访问权限控制,能够成组管理用户和分配权限,能够实现权限的委托管理。Zope还可通过LDAP接口和Windows的活动目录实现用户集成。

Zope目前包括Zope2和Zope3两个分支版本. Zope2基于传统的对象继承技术,目前已经十分稳定,特性丰富,Plone等大型应用均基于Zope2。Zope3是采用最新的设计模式和组件架构技术,对Zope2的重写。在Zope3中,组件之间通过配置文件,按照接口拼装,组装成应用。Zope3采用类似J2EE的对象松耦合架构,同时具备 Python的简洁性和优美性。目前Zope 3已经发展至Zope 3.1版本,很多基于Zope3的项目也逐步开始启动。如,ubuntu Linux的发行管理平台lauchpad(launchpad.ubuntu.com)便采用采用zope3实现. 从Zope 2.8开始,Zope2中也可以使用Zope3的大部分技术,Zope2到Zope3正走向一条平滑过渡的路线。

Zope的中文化目前已经有完整的解决方案,中文Zope用户组(www.czug.org)是国内最专业的Zope技术社区。

讨论