8

私は Zope の初心者で、以前は約 2.5 年間 Django に取り組んでいました。だから私が最初に Zope(v2) に飛び込んだとき (私の新しい会社が 7 年間それを使っていたという理由だけで)、私はこれらの質問に直面しました。それらを理解するのを手伝ってください。

  1. そのようなzodbの「本当の」目的は何ですか? 私はそれが何をするか知っていますが、zodb が行う素晴らしいことと、Django (zodb を持たない) のようなフレームワークが見逃していることを 1 つ教えてください。

    更新: 回答に基づいて、Zodb は ORM の必要性を置き換えます。オブジェクトを db (zodb 自体) 内に直接格納できます。

  2. Zope のキラー機能の 1 つは、TTW (Through the Web または ZMI を使用した開発) 哲学であると言われています。しかし、私 (およびすべての開発者) はファイル システム ベースの開発を好みます (バージョン管理を使用する、Eclipse を使用する、Zope 外のお気に入りのツールを使用する)。では、この TTW は実際にどこで使用されているのでしょうか。

  3. これは大きなものです。Python/Django の継承と比較した場合、Zope の Acquistion はどのような「余分なもの」を獲得しますか。

  4. Django から Zope に移行するのは本当に良いことですか?

  5. Zope(v2) 用の djangosnippets.org のようなサイトはありますか?

4

6 に答える 6

16

まず最初に: 現在の zope2 バージョンには、zope3 もすべて含まれています。また、Plone などの最新の zope2 アプリケーションを見ると、内部で多くの「zope 3」(現在は「zope ツール キット」、ZTK と呼ばれる) が使用されていることがわかります。

ZODB の真の目的: ZODB は、(リレーショナル SQL データベースとは対照的に) 実際に広く使用されている数少ないオブジェクト データベースの 1 つです。オブジェクト リレーショナル マッパーを使用する必要なく、そこにすべての Python オブジェクトを「そのまま」保存できます。ボンネットの下に「select * from xyz」はありません。そして、zodb オブジェクトに新しい属性を追加すると、その変更が「ちょうど」持続します。豪華な！データを厳密なリレーショナル データベースに簡単にマッピングできない場合に特に便利です。簡単にマッピングできる場合は、そのようなデータベースを使用してください。私は、zope プロジェクトで sqlalchemy を数回使用しました。

TTW: そこから戻ってきました。少なくとも、TTW の zope2 方式には、皆さんが恐れているすべての欠点があります。バージョン管理も、外部ツールもありません。Plone は (「器用さ」を Google で検索して) 実験を行っています。ファイルシステムにマッピングできる TTW 開発を行う 3 つの方法があります。

TTW: zodb を使用すると、あらゆる種類の構成設定をデータベースに簡単かつ安価に保存できるため、通常はブラウザーを介して多くのことを調整できます。ただし、これは典型的な TTW 開発とは言えません。

取得: 便利なトリックですが、名前空間が大量に汚染されます。両刃の剣。デバッグ性と保守性を向上させるために、ほとんどの場合、これを使用しないようにしています。取得は「オブジェクトグラフ」内で行われるので、「Zope サイト内のフォルダ構造」と考えてください。3 つ下のフォルダーにある "contact_form" を呼び出すと、中間のどこかに見つからない場合でも、サイトのルートにある "contact_form" を見つけることができます。両刃の剣！

(そして、通常の python オブジェクト指向の継承は、もちろんいたるところで行われます)。

django から zope への移行: 特定の問題に対しては本当に良いアイデアですが、他の問題に対しては無意味です:-) かなり多くの zope2/plone 企業が実際に特定のプロジェクトのためにいくつかの django プロジェクトを行っています。比較的単純な SQL データベースです。コンテンツ管理にもっと興味があるなら、zope (および plone) の方がおそらく優れています。

追加のヒント: zope2 だけに注目しないでください。Zope3 の「コンポーネント アーキテクチャ」には、より大きなアプリケーション (非 Web も含む) を作成するための多くの機能があります。たとえば、使いやすいパッケージ化された Zope についてはgrok ( http://grok.zope.org ) を参照してください。純粋なコンポーネント アーキテクチャは、django プロジェクト内でも使用できます。

于 2009-11-10T13:15:42.743 に答える
7

私はどちらもあまり経験がありませんが、両方を操作する機会があったので、あなたの質問のいくつかについて私の意見を述べることができます.

1）zodb自体の「本当の」目的は何ですか？つまり、私はそれが何をするか知っていますが、zodbが行う素晴らしいことと、django（zodbを持たない）のようなフレームワークが見逃すことを教えてください

ZEO による負荷分散と ZCatalog による検索。この観点では、Django は非常に低レベルです。同じことを達成するには、三角形の多くのホイールを再実装する必要があります。私がすぐに学んだことは、低レベルのデータベースの問題を台無しにしないことです。あなたはそれらを台無しにします。砂丘サイズのワームの缶です。

では、なぜ django ORM を選ぶのでしょうか? YAGNIの場合も考慮する必要があります。django は簡単で自己完結型であり、ドキュメントはプレミアムであり、(もし) サイトが大きくなった場合、後でより優れた ORM (または ZODB の場合は純粋な OODB) に切り替えることになります。

2) Zope のキラー機能の 1 つは、TTW (Through the Web または ZMI を使用した開発) 哲学であると言われています。しかし、私 (およびすべての開発者) はファイル システム ベースの開発を好みます (バージョン管理を使用する、Eclipse を使用する、Zope 外のお気に入りのツールを使用する)。では、この TTW は実際にどこで使用されているのでしょうか。

この質問にはうまく答えられませんが、そのようなアプローチで開発することが根本的に悪いとは言えません。もちろん、これは考え方の変化であり、私もファイルシステム ベースの開発を好む傾向があります。

4) Django から Zope に取り組むのは本当に良いことですか?

Zope 3 は非常にモジュール化されているため、django のコンポーネントの多くを自由に使用できます。私はそれに反対することをお勧めします。もちろんできますが、私が最も問題だと思ったのは、助けが不足していることです。zope コンポーネントと django を同時に使用している人は多くありません。遅かれ早かれ、問題が発生し、Google は役に立ちません。その時点で、もしあなたの人生がビデオゲームだったとしたら、あなたは間違いなくそれを難し​​いレベルでプレイしていることに気付くでしょう (ゾープ コードに鼻を突っ込む必要がある場合は、極端かもしれません)。

于 2009-11-10T08:48:52.517 に答える
6

ZODB に関する非常に優れたリファレンスは、ZODB/ZEO プログラマー ガイドです。. ZODB は ORM ではありません。その真のオブジェクト データベースです。Python オブジェクトは、データベースに適した表現に変換する方法を気にすることなく、透過的にデータベース内に永続化されます。pickle 化可能な Python オブジェクトは、ZODB 内に保存できます。リレーショナル データベースは大量のフラット データ (従業員レコードなど) に適していますが、ZODB は階層データ (通常は Web アプリケーションで見られる) に最適です。私は自分のアプリケーションに Zope 3 を個人的に使用しています。私はTTWタイプの仕事をしたことがありません。ZODB を使用する最大の利点は、データを保存する方法や、ソフトウェアをあるバージョンから次のバージョンにアップグレードするときに状況がどのように変化するかについてまったく心配する必要がないという事実でした。たとえば、Python クラスに新しい属性を追加する場合、クラス属性としてデフォルト値を指定するだけで済みます。その後、同じクラスの以前のバージョンで作成されたすべてのオブジェクトで自動的に使用できるようになります。属性の削除は、既存のオブジェクトに対する単純な del 操作です。ところで、ZODB はあらゆる種類の Python アプリケーションで独立して使用でき、ZOPE プラットフォームだけとは結合されません。ZODB のおかげで、Python アプリケーションで作業しているときに SQL の詳細について心配する必要がないという事実が気に入っています。もちろん、データベース サーバーが必要な場合は、同じサーバーにバックアップされたアプリケーションの複数のコピーを実行できるように、ZODB の上で ZEO が役に立ちます。ZODB のおかげで、Python アプリケーションで作業しているときに SQL の詳細について心配する必要がないという事実が気に入っています。もちろん、データベース サーバーが必要な場合は、同じサーバーにバックアップされたアプリケーションの複数のコピーを実行できるように、ZODB の上で ZEO が役に立ちます。ZODB のおかげで、Python アプリケーションで作業しているときに SQL の詳細について心配する必要がないという事実が気に入っています。もちろん、データベース サーバーが必要な場合は、同じサーバーにバックアップされたアプリケーションの複数のコピーを実行できるように、ZODB の上で ZEO が役に立ちます。

Zope は、オブジェクト発行環境であるという考えから始まりました。その観点から、URL を ZODB のオブジェクト階層に直接マッピングすることは素晴らしいことでした。URL は、オブジェクトの階層を反映するだけです。URL の特定が考慮される限り、常に Rotterdam デバッグ インターフェイスが役立ちます。開発作業では、zope 構成で開発フラグをオンに保ち、Rotterdam インターフェースを介して ZODB の内容を調べます。Rotterdam スキンは、ZODB 内に格納された Python オブジェクトをイントロスペクトする優れた方法を提供し、URL を理解することははるかにインタラクティブです。さらに、私の ZODB 内の主要なコンテナーについては、それらをサイト マネージャー (Zope 3 サイトおよびサイト マネージャー) 内の永続的なユーティリティとして登録します。コードのどこでも、そのようなコンテナーにアクセスする必要があるときはいつでも、私がするのは getUtility(IMyContainerType) だけです。コード ベース内のこれらのコンテナーの詳細な場所を覚えておく必要さえありません。それらは一度サイト マネージャーに登録され、getUtility() 呼び出しを通じてコード ベース内のどこでも使用できるようになります。また、URL は名前空間もサポートしています。たとえば、++skin++ 名前空間を使用すると、Web アプリケーションのスキンをいつでも変更できます。++language++ 名前空間を使用すると、ユーザー インターフェイスの優先言語をいつでも変更できます。++attributes++ 名前空間を使用すると、オブジェクトの個々の属性にアクセスできます。URL は単純に、はるかに強力で、はるかにカスタマイズ可能です。また、トラバーサル アダプターを記述し、独自の名前空間を定義して、URL の機能を強化できます。例を挙げると、Web インターフェイスから直接アクセスできるすべてのページは、私のデフォルトスキンの一部です。バックグラウンド AJAX 呼び出しによって呼び出されるすべてのページは、異なるスキンの下にあります。このようにして、さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。バックグラウンド AJAX 呼び出しによって呼び出されるすべてのページは、異なるスキンの下にあります。このようにして、さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。バックグラウンド AJAX 呼び出しによって呼び出されるすべてのページは、異なるスキンの下にあります。このようにして、さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。別のスキンの下にあります。このようにして、さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。別のスキンの下にあります。このようにして、さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。さまざまなスキンでさまざまな方法の認証メカニズムを実装できます。メイン スキンでは、認証に失敗した場合に別のログイン ページにリダイレクトされます。AJAX ページの場合、単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。単純に HTTP エラーを受け取る可能性があります。これは中央で行うことができます。Zope 3 オブジェクトにはインターフェースがあり、複数のインターフェースに対して 1 つのビューを定義できます。特定のインターフェースをサポートするオブジェクトがあれば、関連するすべてのビューが自動的に使用可能になり、そのような URL はすべて自動的に有効になります。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。考えてみれば、URL がハードコーディングされている単一の Python ファイルや XML ファイルよりもはるかに強力です。私は DJango と J2EE についてよく知らないので、同等の機能があるかどうかはわかりません。

于 2009-11-11T18:20:13.263 に答える
3

ZODBは、スキーマ定義を必要としないOOスタイルのデータベースです。単純に（ほぼ）すべての種類のオブジェクトを作成し、それらを永続化することができます。

TTWが煩わしい場合もありますが、webdavを使用してZOPE-object-treeをマウントできます。次に、お気に入りのエディターを使用してテンプレートとスクリプトを編集できます。

ZOPEは、CMSのようなシステムを作成するのに特に強力ですが、私見ではまだ比類のないものです。Djangoで同等に機能させるには、多くのことを経験する必要があります。

そしてTTWを通じて、実際にはデザイナーのような非開発者は、開発者の介入を必要とせずに、たとえばテンプレートやCSSを開発する可能性が高くなります。

于 2009-11-10T11:04:52.850 に答える
1

上記のWheatの答えに+1：「Zope2は、歴史的な観点から学ぶことだけが本当に興味深い」。大規模なサイトでZopedevを数年間、50％zope 2、50％zope 3で行いました。それでも（これは2年前でした）、zope2からすべてを移行する作業を行っていました。既存のZope2プロジェクトに投資しているので、それを使用する理由はありません。そこには未来があまりありません。また、既存の大きなzope 2プロジェクトがある場合は、 Five（ジョーク：2 + 3 = 5）を対象とした製品を見てみることをお勧めします。

Zope3テクノロジーをZope2に統合できます。特に、Zope 3インターフェース、ZCMLベースの構成、アダプター、ブラウザーページ（スキン、レイヤー、リソースを含む）、スキーマに基づく自動追加および編集フォームを使用できます。 、オブジェクトイベント、およびZope3スタイルのi18nメッセージカタログ。

すべてを語り終えると、Zope 3は2とは非常に異なるフレームワークであり、IMHOは（より複雑ではありますが）はるかに優れたフレームワークです。TTWはオプションであり、ほとんどの場合推奨されません。暗黙の買収はなくなりました。

ここの人々はあなたがZODBを使いたいと思う理由をカバーしているように見えるので、私はZope 3（またはFiveを使用するZope 2）についてもう1つ言及したいと思いました。Zopeには、 Zope Component Architecture（ZCA）と呼ばれるさまざまなアプリケーションコンポーネントを相互に接続するための非常に強力なシステムがあります。それはあなたが多かれ少なかれ自律的で再利用可能であり、標準化された方法で一緒に接続することができるコンポーネントを書くことを可能にします。私は主にDjangoの開発を行っていますが、ZCAを見逃していることもあります。Djangoでは、再利用可能なコンポーネントを作成する機能は制限されており、アドホックなものです。しかし、Reinoutが言うように、zope.component（ZODBを含むほとんどのzopeパッケージのように）はzopeフレームワークの外で機能し、Djangoプロジェクトで使用できます。

とはいえ、ZCAには欠点があります。その1つは、コンポーネントをXMLファイルに登録するという面倒なプロセスです。それはいつも私に少しJava-esqeを感じました。私がGrokhttp: //grok.zope.org/を本当に気に入っている理由の1つは、それがzope.componentの上にあり、そのうなり声の多くをあなたのためにやってくれるからです。

つまり、結論：Zope2はほとんど行き止まりです。雇用主がそれに従順である場合は、Zope 3、または少なくとも5を検討し始めてください。Zope 3はDjangoに比べて学習曲線が急であることがわかると思います。そのため、Zope3の粗いエッジの多くを滑らかにするGrokを介して学習することをお勧めします。しかし、可動部分がたくさんある非常に大規模または複雑なWebアプリケーションの場合は、DjangoよりもZopeを選びます（これは、Djangoが大好きな人だと思います）。小規模なプロジェクトの場合、Djangoの方がおそらく高速です。ただし、このコンテキストで「大きい」と「小さい」を定量化することは困難であり、おそらくさらに数千語が必要になります。Zope 3に本当に興味があるなら、PhilippvonWeitershausenの本が間違いなく出発点です。

于 2009-11-14T20:41:26.070 に答える