Zope2と3の違い、雑感。

今回は、Zope2との違いを考えてみました。本当は表を作って機能単位で、ここが違う、あそこは一緒とかできればいいんですが、Zope3を使いこんでいないので分かりません。そこで、まとまりがないですが、とりあえず思いついたことを書いてみたいと思います。 (2005/9/27 OSSWebで公開した文書です)

基本は一緒

違いを書くといいながら恐縮ですが、変わっていない部分もあります。それは Zopeの名前の由来でもあるObjectPublishingという一番基本的なアイディアです。

Zopeの機能を大雑把に分けると、

マルチプロトコルサーバ(http,ftpなど)
オブジェクトパブリッシャー
オブジェクトデータベース
アプリケーション

となります。この構成はZope2と3で変わっていません。Pythonの永続オブジェクトのツリーがウェブサイトになっている、オブジェクトにアクセスさせて処理結果を返すというところは同じです。

よりPythonらしくなった。

大々的に言われていることなんですが、Zope3はよりPython的、Pythonに親和性の高い設計になっています。

例えば、アプリケーションをPythonのパッケージとして作るようになったのがそうです。Zope2のときはプロダクトというZope独自の拡張方法で作っていました。

ユーザが作るアプリケーションだけではなくて、Zope3自身がそのように作ってあります。だから、zopeをsite-packagesに入れることができます。Zope3の機能の一部(例えば、publisherとかzodbとかinterface)だけを自分の他のプログラムに使うこともできます。

distutilsを使って自作ソフトウェアを配布できるようにもなります。

また、APIもよりPython的になっています。コンテナ(フォルダ)のAPIはdict (辞書)のようになりました。Zope2ではObjectManagerというコンテナクラスがあって独自のAPIを持っていました。

今までのZopeはPythonで作られている独特の箱庭ソフトでしたが、Zope3は Pythonのライブラリになったという気がします。

逆にいうと、箱庭的要素が減って(まだそこまで手が回っていないという面もあります)、Pythonの知識と経験が今までよりも必要になったと思います。

Zope的黒魔術の減少

前の話と一緒なんですが、よりPythonらしくなったことで、Zope的黒魔術 (Zopeに固有の様々な決まりごと)がほとんど無くなりました。

ちょっと例を挙げてみます。掲示板クラスを書いてみました。

Zope2のコード

class BBS(Folder):

    meta_type = 'MyFolder'

    security = ClassSecurityInfo()

    secirity.declareProtected(EditContent, 'post')
    def post(self, message):
       pass
InitializeClass(BBS)

Zope3のコード

class BBS(Folder):

    implements(IBBS)

    def post(self, message):
        pass

Zope2のコードには、meta_typeとかsecurityとか、クラスを宣言したら InitializeClassに通してやらないと駄目とか、いろいろ決まりごとがあります。この決まりごとを覚えるのがなかなか大変なのです。

それに比べるとZope3のコードには余計なものがほとんど付いていません。 Zope3をまったく知らないPythonプログラマがソースコードをみて、おやっと思うのはzope.interfaceに関する部分(implementsのところ)だけでしょう。

Zope3では2にあったクラスに付いてくる余計なもの(セキュリティ設定など)が全てZCMLに掃き出されました。そのため、クラスは非常にシンプルに、必要なことだけを書けばよくなりました。とてもありがたいことです。

しかし、ZCMLという黒魔術が増えたじゃん、と仰る方がいるかもしれません。まぁ、たしかに覚えなければいけない要素は増えていますが、クラスの中にまぜこぜで入ってくるよりも遥かにマシなものです。

それにZCMLははじめこそ何だこりゃと思うかもしれませんが、使ってみるとあっという間に慣れてしまいました。宣言的に書けるので、なにがどうなっているのか良く分かって便利です。apidocというドキュメンテーションツールを使えば、ZCMLのディレクティブの使い方をすぐに調べられるので、書くのはそれほど難しくありません。

ドキュメントがある

ドキュメントがある、これはありがたい。そう、Zope2にはロクなドキュメントがなかったのです。

HelpSystemというものがありましたが、載っているAPIはごく一部。あまり当てにはなりませんでした。あってないようなものです。

Zope2は増築を繰り返して巨大なダンジョンになってしまったので、何がどうなっているか、実際に歩き回って調べてみる他ありませんでした。

歴史的経緯なんだろうし、それも仕方がないとは思うのですが、明確な設計方針とドキュメントがあるに越したことはないですよね。フルスクラッチされた Zope3にはそれがあります。zope.interfaceを中心としたコンポーネントアーキテクチャという設計で統一されているので、ApiDocという自動ドキュメント生成ツールを使って、Zopeの中身を調べることができます。

ファイルシステムベースでの開発

Pythonパッケージとしてアプリケーションを開発する、ということから分かるとおり、Zope3ではファイルシステムベースでの開発が中心となります。

Zope2では二種類の開発方法があって、ZMI上でDTMLなどを使って開発する場合とCMFを使ってファイルシステム上で開発する場合があります。CMFを使うと一応ファイルシステムベースでの開発ができるのですが、数が多くなるビジネスロジックがスキン機能に集中してしまって色々と問題がありました。

Zope3のファイルシステムベースのプログラムはZope2と違って全てが通常の Pythonの実行環境上で処理されるため、プログラムを部品化しやすくなっています。また、それぞれの機能はZopeを起動したり全機能を読み込まなくても単体で実行できるため、デバッグやテストコードが書きやすくなっています。

強力な抽象化機構

Zope2にはアプリケーション作成時にこんな方法で作るべし、というような抽象化の方法は特に提示されていませんでした。多重継承が頻繁に使われているなぁという印象があるくらいです。

CMFでは抽象化の方法が提示されていて、CMFを使ったアプリケーションはほとんどツールとコンテンツという概念で開発されていると思います。しかし、 CMFはあくまでZope2の上に乗っているアドオンであるため、中途半端なところがありました。実際、CMFを使っていてうまく抽象化できないような場合もありました。

また、Zope2では機能を拡張するために動的な関数の上書きなどのトリック(モンキーパッチ)を頻繁に使っていましたが、これも色々と問題がありました。

Zope3では一貫してコンポーネントアーキテクチャという抽象化の方法が用いられています。簡単にいえばzope.interfaceを使うということなんですが、これが徹底されています。アダプタを書いて機能を拡張できるので、モンキーパッチは必要はありません。

インターフェースの概念はZope2にもありましたし、CMFでも一応使われてはいるのですが、全く有効に使われていませんでした。Zope2のインターフェースにはアダプテーション機能がないため、Zope3のコンポーネントアーキテクチャに比べるとかなり貧弱にみえます。

充実したテスト機能

上でも少し触れましたが、Zope3はファイルシステムベースの開発になったこともあり、既存のテスト手法が有効に使えるようになりました。

Zope2はサードパーティー製のテスト用プロダクトがいくつも公開されていますが、本体には同梱されていません。

Zope3では標準で3つのテストライブラリが組込まれて、簡単にアプリケーションに組込めるようになっています。Zope3自体の開発でテストを必ず書くように徹底されています。

unittest Pythonのunittestモジュールが使えます。

doctest Pythonのdoctestモジュールが使えます。

functionaltest 実際のアプリケーションの動作テストをunittest形式で行えるモジュールがあります。

セキュリティ機構

まだちゃんと理解していませんが、Zope2のセキュリティとは随分違ったものになっているようです。

Zope2ではオブジェクトにセキュリティタグを付けて、制限付きの実行環境で評価したときのそのタグをみてセキュリティチェックをしていました。

ところがZope3では、オブジェクトをプロキシオブジェクトというラッパーで包んでアトリビュートへのアクセスを制限する、という方式になったようです。

これにより、Zope3では普通のPythonの実行環境でもセキュリティが有効になっています。Zope2ではプロダクトのレベルで書いたPythonのコードではなんでもやりたい放題できたので、これは変わったなぁと思いました。

まとめ

はじめのほうに書きましたが、Zope2がPythonで作られた箱庭ソフトであるなら、Zope3はPythonライブラリ、という感じでしょうか。

最初のZope2はDTMLしかなかったそうなので、元々はそういうソフトなんだと思います。しかし、だんだんとウェブアプリケーションの要求水準が高くなってきて、Pythonをそのまま使えるほうが都合が良くなった結果、Zope3はより Pythonっぽくなったということかもしれません。

Zope3は基盤がしっかりしているので、将来この上で動く箱庭ソフトがでてきてもおかしくない気がします。Zope2はZMIという箱庭を作るために作ったソフトなので、それを汎用的なソフトウェア開発に使うからいろいろ無理がでてきているような気がしますが、Zope3なら色々な箱庭を作るのに向いていそうです。

最終更新日: 2007/02/19