从Django眼中了解Zope内部

Question

我是zope的新手,之前我在Django工作了大约2.5年.因此,当我第一次跳入Zope(第2版)时(仅因为我的新公司7年来一直使用它),我遇到了这些问题.请帮助我理解它们.

1. zodb的"真正"目的是什么？我知道它做了什么,但告诉我zodb做的​​一件好事和像Django(没有zodb)这样的框架未命中.

   更新:根据答案,Zodb取代了对ORM的需求.您可以直接将对象存储在db(zodb本身)中.

2. 据说,zope的杀手功能之一是TTW(通过网络或使用ZMI开发)的理念.但我(和任何开发人员)更喜欢基于文件系统的开发(使用Version控件,使用Eclipse,使用Zope之外的任何喜欢的工具).那TTW实际上在哪里使用？

3. 这是一个很大的问题.与Python/Django继承相比,Zope的Acquistion获得了什么"EXTRA Stuff".

4. 来自Django的Zope真的是一个很好的举动吗？

5. 任何网站如djangosnippets.org for Zope(v2)？

Answer 1

第一件事:当前的zope2版本也包括所有zope3.如果你看看像Plone这样的现代zope2应用程序,你会发现它使用了大量的"zope 3"(现在称为"zope工具包",ZTK).

ZODB的真正目的:它是少数几个对象数据库(与关系SQL数据库相对)之一,它们被广泛使用.您可以"只"将所有python对象存储在那里,而无需使用对象关系映射器.引擎盖下没有"选择*来自xyz".并且在zodb对象上添加一个新属性"just"会持续存在这种变化.豪华!当您的数据无法轻松映射到严格的关系数据库时,尤其方便.如果你可以轻松地映射它:只使用这样的数据库,我在zope项目中使用了sqlalchemy几次.

TTW:我们从那里回来了.至少,TTW的zope2方式确实具有你担心的所有缺点.没有版本控制,没有外部工具等.Plone正在尝试(谷歌的"灵巧")与良好的显式zope 3方式进行TTW开发仍然可以映射回文件系统.

TTW:zodb使得在数据库中存储各种配置设置变得简单而便宜,因此您通常可以通过浏览器调整很多东西.不过,这并不算作典型的TTW开发.

收购:方便的技巧,虽然它导致巨大的命名空间污染.双刃剑.为了提高可调试性和维护性,我们在大多数情况下都尝试不用.采集发生在"对象图"内部,因此请考虑"zope站点内的文件夹结构".调用"contact_form"三个文件夹仍然可以找到网站根目录下的"contact_form",如果在其间找不到它.双刃剑!

(当然,常规的python面向对象继承发生在各处).

从Django中移动到Zope的:对某些问题和一个很好的主意荒谬了:-)相当多zope2的/ Plone的公司实际上已经做了一些Django的项目,具体项目等问题,通常是那些在其内容的99%百分一个相对简单的SQL数据库.如果你更喜欢内容管理,那么zope(和plone)可能会更好.

补充提示:不要只关注zope2.Zope3的"组件架构"具有许多用于创建更大应用程序(也非非Web)的功能.例如,请查看grok(http://grok.zope.org)以获得友好的打包zope.纯组件体系结构也可以在django项目中使用.

Answer 2

在ZODB上:

另一种问题是"ZODB的真正目的是什么？" 是问,"为什么最初创建ZODB？"

答案就是这个项目是在1996年左右开始的.这是在MySQL或PostgreSQL存在之前,当时miniSQL(一个免费但不是免费的软件)数据库仍然普遍使用,或者是大笔资金Oracle等数据库.Python提供了pickle模块来将Python对象序列化到磁盘 - 但是序列化是较低级别的,它不允许诸如事务,并发写入和复制之类的功能.这就是ZODB提供的功能.

它现在仍然在Zope中使用,因为它运行良好.如果在realational数据库中没有现有的技能组,则学习使用ZODB比使用关系数据库更容易.它也是可用的更简单的用例,例如,如果你有一个需要存储一些配置信息的命令行脚本,使用关系数据库意味着必须运行数据库服务器只是为了存储一些配置.您可以使用配置文件,但ZODB也可以很好地工作,因为它是一个可嵌入的数据库.这意味着数据库在与其余Python代码相同的进程中运行.

值得注意的是,用于在容器内存储对象的API在Zope 2和Zope 3之间是不同的.在Zope 2中,容器存储为属性:

 root.mycontainer.myattr

在Zope 3中,它们使用与Python标准字典类型相同的接口:

  root['mycontainer']myattr

这是为什么学习使用ZODB比使用Django ORM更容易的另一个原因,因为Django有自己的ORM接口,它与Python的现有接口不同.

通过网络(TTW):

再次,了解TTW的原因可以追溯到Zope开发之时.虽然打破众所周知的开发者工具如Subversion或Mercurial似乎很愚蠢,但Zope是在90年代后期开发的,当时唯一的免费版本控制系统是CVS.Zope 2拥有它自己的简单版本控制功能,它们和CVS一样好(也就是说,"它们是有限的和笨拙的.").当时UNIX工作站的成本要高得多,而且资源也少得多,因此系统管理员对如何管理服务器更加谨慎和谨慎.TTW允许那些通常无法通过sysadmin intervation将代码上传到服务器的人这样做.

使用文本编辑器,emacs和vi都有ftp-mode,而Zope 2可以在FTP端口上侦听.这将允许您进行开发,以便代码存储在ZODB(可编辑的TTW)中,但通常使用emacs或vi编辑此代码.

今天在Zope,TTW更少使用或推广,因为它不再有意义.磁盘空间便宜,服务器(相对)便宜,并且有许多开发人员工具希望与标准文件系统进行交互.

采集:

那是一个错误.这是一个非常令人困惑的功能,导致许多意想不到的事情发生.从理论上讲,有一些有趣的想法可以用于获取,但实际上它最好被扔进垃圾箱并且几乎没有实际用途.

从Django迁移到Zope:

2001年开始在Zope 3上开展工作.这解决了Zope 2的许多问题.这是Zope社区的一个证明,Zope 2仍然是积极和良好的维护,但它几乎不是最先进的.从历史的角度来看,Zope 2真的很有趣.

Zope 3最终在几个不同的方向上进化,因此Zope的现代化身最好以Grok,BFG或Bobo的形式表达.

Grok最接近Zope 3,因此是一个非常大的框架 - 在钻研它的代码库时,它有时会非常压倒性.但是,就像Django或任何其他全栈框架一样,您不需要使用Grok的每个部分,可以很容易地学习基础知识并使用它创建Web应用程序.它的常规配置是首屈一指的,它的基于类的视图使它比Django Web应用程序更加严格,可以说是更清晰的代码库.它的URL路由系统非常灵活,但也可以说是过度设计的.

BFG是由Zope开发人员Chris McDonough撰写的"只为您吃的东西付费"的框架.因此,它在精神上更接近Pylons,其中仅包括被认为是框架的核心或必要部分.它也适用于WSGI.它只使用了一些核心Zope包.

Bobo是一个"微框架".这只是一种路由URL和提供应用程序的方法.它不使用任何Zope包,因此严格来说不是Zope系列的Web框架.但它是由Zope的创作者Jim Fulton编写的,他最初称Zope的出版部分为"Bobo".原始的Bobo,写于90年代早期,将URL映射到包和模块,因此如果您的源代码被布置为:

mypackage.mymodule.MyClass

你可以有一个URL,如:

/mypackage/mymodule/MyClass

这是非常不灵活的,并在Zope 2中被URL Traversel取代,这是相当复杂的.Bobo使用Routes,因此它是死亡简单URL解析和复杂URL解析之间的中间地带 - 与Django的URL解析机制大致相同.

Answer 3

我回答没有太多经验,但我有机会操纵两者,所以我可以告诉你我对你的一些问题的看法.

1)zodb的"真正"目的是什么？意思是我知道它做了什么,但告诉我zodb做的​​一件好事和像django这样的框架(没有zodb)未命中

通过ZEO进行负载分配并通过ZCatalog进行搜索.从这个角度来看,Django的水平很低.要实现同样的目标,你必须重新实现很多轮子,三角形.我很快就学到的东西是:不要搞乱低级数据库问题.你会搞砸他们.它是一种蠕虫,沙丘大小.

那么为什么选择django ORM呢？您还应该考虑是否YAGNI.django很容易且是自包含的,文档是高级的,当(如果)你的网站增长那么多时,你将在以后切换到更好的ORM(或者在ZODB的情况下转换为纯OODB).

2)据说zope的杀手功能之一是TTW(通过网络或使用ZMI开发)的理念.但我(和任何开发人员)更喜欢基于文件系统的开发(使用Version控件,使用Eclipse,使用Zope之外的任何喜欢的工具).那TTW实际上在哪里使用？

我无法正确回答这个问题,但我不会说用这种方法开发是根本不好的.当然,这是思维方式的改变,我倾向于更喜欢基于文件系统的开发.

4)从Django到Zope工作真的是一个很好的举动吗？

Zope 3非常模块化,因此您可以自由使用django的许多组件.我会建议反对它.当然,你可以,但我发现最有问题的是缺乏帮助.没有多少人同时使用zope组件和django.迟早,你会遇到问题,谷歌也无济于事.在那一点上,你会意识到,如果你的生活是一个电子游戏,你肯定是在难度级别(也许是极端,如果你不得不把你的鼻子放入zope代码).

Answer 4

关于ZODB的一个非常好的参考是ZODB/ZEO程序员指南.ZODB不是ORM.它是一个真正的对象数据库 Python对象在数据库中透明地保留,而不用担心如何将它们转换为适合数据库的表示.任何pickleable Python对象都可以保存在ZODB中.关系数据库适用于大量平面数据(如员工记录),而ZODB最适合分层数据(通常在Web应用程序中找到).我个人使用Zope 3作为我的应用程序.我从未做过TTW类型的工作.使用ZODB的最好的部分是我从来不必担心如何保存数据以及当我将软件从一个版本升级到下一个版本时会发生什么变化.例如,如果我向Python类添加一个新属性,我所要做的就是提供一个默认值作为类属性.然后,它将自动可用于使用同一类的先前版本创建的所有对象.删除属性是对现有对象的简单del操作.BTW,ZODB可以在任何类型的Python应用程序中独立使用,并且不与ZOPE平台耦合.我喜欢这样一个事实,即在处理Python应用程序而不是ZODB时,我不必担心SQL的细节.当然,如果您需要一个数据库服务器,以便您可以运行由同一服务器支持的应用程序的多个副本,ZEO将在ZODB之上进行救援.

Zope最初的想法是成为一个对象发布环境.从这个角度来看,将URL直接映射到ZODB中的对象层次结构非常棒.URL仅反映对象的层次结构.现在只要考虑URL,就会有鹿特丹调试界面的帮助.对于开发工作,我在zope配置中保持开发标志,并通过Rotterdam接口查看ZODB的内容.鹿特丹皮肤提供了一种很好的方式来反省存储在ZODB中的Python对象,并且确定URL更具交互性.此外,对于我的ZODB内的主要容器,我将它们注册为站点管理器(Zope 3站点和站点管理器)中的持久性实用程序.在我的代码中的任何地方,每当我需要访问这样的容器时,我所做的就是getUtility(IMyContainerType).我甚至不必记住代码库中这些容器的详细位置.它们曾经在站点管理器中注册,并通过getUtility()调用在代码库内的任何地方可用.URL也支持名称空间.例如,使用++ skin ++命名空间,您可以随时更改Web应用程序的外观.使用++ language ++命名空间,您可以随时更改用户界面的首选语言.使用++ attributes ++命名空间,您可以访问对象的各个属性.URL功能更强大,更易于定制.您可以编写遍历适配器,定义自己的命名空间,以增强URL的功能.举一个例子,所有可以从Web界面直接访问的页面都是我的默认皮肤的一部分.虽然通过后台AJAX调用调用的所有页面都在不同的皮肤下.这样,可以在不同的皮肤中实现不同的认证机制方式.在主皮肤中,如果身份验证失败,则会将其重定向到不同的登录页面.对于AJAX页面,人们可能只会收到HTTP错误.这可以集中完成.Zope 3对象具有接口,可以为多个接口定义一个视图.只要您拥有支持给定接口的对象,所有关联的视图都将自动可用,并且所有此类URL都自动有效.如果你考虑一下,它比一个python文件或XML文件更强大,其中URL是硬编码的.我对DJango和J2EE并不是很了解,所以不能说它们是否具有相同的功能.