http://oss.timedia.co.jp/index.fcgi/kahua-web/show/Zope3/Zope2%a4%c83%a4%ce%b0%e3%a4%a4%a1%a2%bb%a8%b4%b6%a1%a3
Zope3の特徴を列挙。
- Python との親和性が高くなった
- Zope 独自の黒魔術が少なくなった
- ドキュメントがある!
- ファイルシステムベースで開発ができる
- 一貫したコンポーネントアーキテクチャによる抽象化
- テスト機能の充実
- セキュリティ機構の変更
Zope2がPythonで作られた箱庭ソフトであるなら、
Zope3はPythonライブラリ、という感じでしょうか。
全然別物だなあ。
Zope2 では、どんなデータでもオブジェクトとして、
ZODB に格納して、そのオブジェクトにアクセスすることで、
表示や、アプリケーション動作などをやらせる、
というアーキテクチャで、とても格好良い。
でも深くいじるには、そのアーキテクチャをまずちゃんと
理解しないといけなくて、敷居が高かったのかもなあ。
他のアプリケーションフレームワークは、ほぼすべて
ファイルシステムベースなわけだし。
参考) ZODB How-To(日本語訳)
http://wiki.zope.jp/ZODB%20How-To
おそらく Zope の初期の目標は、
DTML と Product という便利なものを使える箱庭を作る、
ちょっとイケてるウェブサーバを作る、
というもので、初期のユーザはその箱庭で遊んで、楽しいねえ、
便利だねえ、と言ってたのが、
意外と流行ってしまったために、ユーザ層が変化して、
- 他のシステムとの親和性をより高く、
- 開発者により優しく、
- CMF としてより使いやすく
- でも Zope 独特の便利さはある程度そのままに、
というような要望が出てきたんだと思う。
要望に答えるためには、アーキテクチャをがらっと変える
必要があった、と。
実際に変えちゃったのはすごいパワーだ。
本家のページを眺めてみたら、そんな記述もあるね。
Zope 3 Project VisionStatement
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VisionStatement
Zope 3 Project WiKi
http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage
拡張ライブラリの呼び方も違う。
Product ではなく Add-on Packages なのね。