たくさんの開発者が、比較的柔軟な環境でZend Frameworkプロジェクトのための 最善のプロジェクト構造のガイダンスを望みます。 「柔軟な」環境とは、 それらのアプリケーションを実行し、かつ安全にするための 最も理想的なプロジェクト構造を達成するために、 必要に応じてそれらのファイルシステムとウェブサーバ構成を開発者が操作できる 環境です。 デフォルトのプロジェクト構造では、 それらの配置で開発者がそのような柔軟性を持つと仮定します。 以下のディレクトリ構造は、 複雑なプロジェクトのために最大限に拡張可能に設計されています。 その一方で、プロジェクトのためのフォルダとファイルの単純なサブセットを より単純な必要条件で提示します。 この構造も、モジュラー及び非モジュラー両方のZend Frameworkアプリケーションのために、 変更なしで動作します。 .htaccessファイルは、 この付録に含まれるリライト構成ガイド で定めるウェブサーバでも、URLリライト機能を必要とします。 このプロジェクト構造で、可能性があるすべてのZend Frameworkプロジェクト条件を サポートすることは意図していません。 Zend_Toolによって使われるデフォルトのプロジェクト・プロフィールは、 このプロジェクト構造を反映します。 しかし、この構造でサポートされない必要条件を持つアプリケーションでは、 カスタム・プロジェクト・プロフィールを使わなければなりません。 / application/ configs/ application.ini controllers/ helpers/ forms/ layouts/ filters/ helpers/ scripts/ models/ modules/ services/ views/ filters/ helpers/ scripts/ Bootstrap.php data/ cache/ indexes/ locales/ logs/ sessions/ uploads/ docs/ library/ public/ css/ images/ js/ .htaccess index.php scripts/ jobs/ build/ temp/ tests/ ]]> 以下では、一覧に記載されたディレクトリ毎に利用例を記述します。 application/: このディレクトリは、アプリケーションを含みます。 構成や利用されるサービス、及びブートストラップ・ファイルと同様に、 MVCシステムを収納します。 configs/: アプリケーション全体の設定のディレクトリ controllers/, models/, views/: これらのディレクトリは、デフォルトのコントローラ、モデルまたは ビューのディレクトリとして用いられます。 アプリケーション・ディレクトリの中にこれらの３つのディレクトリを持たせると、 グローバルな controllers/models/views を持つ モジュラー・プロジェクトと同様に、 単純なプロジェクトを始めるための最良のレイアウトが提供されます。 controllers/helpers/: これらのディレクトリにはアクション・ヘルパーを含みます。 アクション・ヘルパーは、デフォルト・モジュールのための "Controller_Helper_"、 または他のモジュールの "<Module>_Controller_Helper" として namespace されます。 layouts/: このレイアウト・ディレクトリは、 MVC ベースのレイアウト用です。 Zend_Layout は MVC ベース、 及び非 MVC ベースのレイアウトができるので、 このディレクトリの位置は、レイアウトがコントローラとは１対１の関係ではなく、 views/ 内のテンプレートから独立していることを反映します。 modules/: モジュールにより、開発者は 一組の関連したコントローラを論理的に系統化されたグループに分類できます。 モジュール・ディレクトリ配下の構造は、 アプリケーション・ディレクトリ配下の構造に似ています。 services/: このディレクトリは、 アプリケーションによって、 またはモデルのためのサービス・レイヤ を実装するために提供される、 アプリケーションに依存したウェブ・サービス・ファイルのためのものです。 Bootstrap.php: このファイルはアプリケーションのためのエントリ・ポイントで、 Zend_Application_Bootstrap_Bootstrapper を実装するべきです。 このファイルのための目的は、アプリケーションを起動すること、 及びそれらを初期化することによって、コンポーネントがアプリケーションを利用できるようにすることです。 data/: このディレクトリは、 揮発性でおそらく一時的なアプリケーションのデータを格納するための場所を提供します。 このディレクトリのデータの障害は、アプリケーションが失敗する原因になるかもしれません。 また、このディレクトリの情報は、サブバージョン・リポジトリに関与するかもしれませんし、 関与しないかもしれません。 このディレクトリの物体の例は、 セッション・ファイル、キャッシュ・ファイル、sqlite データベース、 そしてログとインデックスです。 docs/: このディレクトリは、生成されたか、または直接編集された ドキュメンテーションを含みます。 library/: This directory is for common libraries on which the application depends, and should be on the PHP include_path. Developers should place their application's library code under this directory in a unique namespace, following the guidelines established in the PHP manual's Userland Naming Guide, as well as those established by Zend itself. This directory may also include Zend Framework itself; if so, you would house it in library/Zend/. public/: このディレクトリは、アプリケーションのためにすべての公開ファイルを含みます。 index.php sets up and invokes Zend_Application, which in turn invokes the application/Bootstrap.php file, resulting in dispatching the front controller. The web root of your web server would typically be set to this directory. scripts/: このディレクトリは、メンテナンスやビルド・スクリプトを含みます。 Such scripts might include command line, cron, or phing build scripts that are not executed at runtime but are part of the correct functioning of the application. temp/: The temp/ folder is set aside for transient application data. This information would not typically be committed to the applications svn repository. If data under the temp/ directory were deleted, the application should be able to continue running with a possible decrease in performance until data is once again restored or recached. tests/: This directory contains application tests. These could be hand-written, PHPUnit tests, Selenium-RC based tests or based on some other testing framework. By default, library code can be tested by mimicing the directory structure of your library/ directory. Additionally, functional tests for your application could be written mimicing the application/ directory structure (including the application subdirectory). The directory structure for modules should mimic that of the application/ directory in the recommended project structure: configs/ application.ini controllers/ helpers/ forms/ layouts/ filters/ helpers/ scripts/ models/ services/ views/ filters/ helpers/ scripts/ Bootstrap.php ]]> The purpose of these directories remains exactly the same as for the recommended project directory structure. URL rewriting is a common function of HTTP servers. However, the rules and configuration differ widely between them. Below are some common approaches across a variety of popular web servers available at the time of writing. All examples that follow use mod_rewrite, an official module that comes bundled with Apache. To use it, mod_rewrite must either be included at compile time or enabled as a Dynamic Shared Object (DSO). Please consult the Apache documentation for your version for more information. Here is a very basic virtual host definition. These rules direct all requests to index.php, except when a matching file is found under the document_root. ServerName my.domain.com DocumentRoot /path/to/server/root/my.domain.com/public RewriteEngine off RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ /index.php [NC,L] ]]> Note the slash ("/") prefixing index.php; the rules for .htaccess differ in this regard. 下記はmod_rewriteを利用する .htaccessファイルの例です。 It is similar to the virtual host configuration, except that it specifies only the rewrite rules, and the leading slash is omitted from index.php. mod_rewriteを設定する方法はたくさんあります。 もし、詳細をお好みでしたら、Jayson Minard のBlueprint for PHP Applications: Bootstrappingをご覧下さい。 As of version 7.0, IIS now ships with a standard rewrite engine. You may use the following configuration to create the appropriate rewrite rules. ]]>