私自身、ZF初心者として、OPが理解しようとしていることのいくつかを理解していると思います。それで、私が理解していることを少し説明します。これは、OP(または、元の質問が非常に古く、OPがZFになっていることを想像しているため、将来の読者に役立つ可能性が高い)のいずれかに役立つことを願っています。達人)。
ZFは主に「自由に使用」できると主張しているため、Zend_Application、Zend_Bootstrapクラス、MVCアプローチ全体などの構造全体を購入する必要はありません。
さらに、簡単な自動読み込みを可能にするクラスの命名とファイルの場所の規則を理解しています。例:class App_Model_User
フォルダにありますApp/Model/User.php
混乱を招く可能性があるのは、スクリプトコンテキストでは、まだ行っていないことだと思います。
- すべてのリクエストをにプッシュする.htaccessマジックを実行しました
public/index.php
APPLICATION_PATH
にパスを設定して含めるpublic/index.php
- 構成ファイルに関連付けられた
Application
またはオブジェクトを作成しましたBootstrap
そのコンテキストで得られ、別のコンテキストで必要なZFの良さのほとんどをどのように活用するのが最善かは、少し不明確になる可能性があります。
元の質問に対する私の答えは、通常のエントリポイントシーケンスは
httpリクエスト->.htaccess->index.php-> config
私たちのために私たちの環境の多くをセットアップします、私たちは異なるエントリーパスのためにそれのいくつかを複製する必要があるでしょう。
したがって、スクリプトの場合、私の最初の本能は、index.phpで発生することの多くを反映する共通のインクルードファイルを作成することです。インクルードパス、APPLICATION_PATHを設定し、ブートストラップをインスタンス化して呼び出し、スクリプト固有の処理を実行します。 。
さらに良いことに、http / webコンテキストで行うように、すべてのスクリプトに対して単一のエントリポイントを作成することが望ましい場合があります。独自のスクリプト目的でZend_Applicationを拡張$application->run();
して、MVC router-controller-dispatch処理を開始せず、独自の処理を実行するようにします。このように、この単一のスクリプトエントリポイントはWebエントリポイントとほぼ同じに見えますが、唯一の違いは、インスタンス化されるアプリケーションオブジェクトです。次に、目的のアプリケーションクラスの名前をコマンドラインパラメータとしてスクリプトに渡します。
しかし、ここで私は自信がなく、ただアイデアを捨てることを告白します。
これがすべて誰かを助けることを願っています。それは実際に私がそれをすべて書き留めるのを助けました。ありがとう、乾杯!
更新2009-09-29:この記事に出くわしました:コマンドラインからのZendFrameworkの使用
アップデート2009-11-20:そして別の記事:ZendFrameworkのcronジョブ| GSデザイン
アップデート2010-02-25: Zendアプリケーションを使用した簡単なコマンドラインスクリプト-David Caunt