Zend Framework 2に慣れる過程で、公式Webサイト（ http://framework.zend.com/manual/2.2/en/user-guide/overview.html ）からチュートリアルを学び、フレームワークのドキュメント（ http：//framework.zend .com / manual / 2.2 / ja / index.html ）、Michael Romerの著書「Zend Framework 2によるWeb開発」を読んで、彼自身のテストアプリケーションを作成します。
このすべての情報を消化して、フレームワークの公式チュートリアルはかなりドライであるという結論に達しました。
- ユーザー、セッション、アクセス権の取り扱いについては言及していません。
- ただ通過するのは、ServiceManagerが考慮したフレームワークの基本的な部分です
- テーブルゲートウェイパターン（およびフレームワーク内の対応する実装）は、データベースとのインターフェースとして使用されます。
- フレームワークに組み込まれたテンプレートエンジンを使用します。これは、Python Jinja 2の後、完全に不快で原始的なように見えます
- など
その結果、この本を読んだ後、多かれ少なかれ満足のいく機能アプリケーションを作成することができました。
この記事では、シンプルなブログの開発例を紹介しますが、公式のチュートリアルとはいくつかの違いがあります。 まず、研究中に公式チュートリアルで十分に開示されていなかった問題に焦点を当てようとします。 さらに、Zendフレームワークでデフォルトで使用されている技術に代わるいくつかの技術を使用します。
- Twigはテンプレートエンジンとして使用され、
- データベースを操作するために-Doctrine ORM 、
- 承認/認証およびアクセス権の配布には、既存のZfcUserおよびBjyAuthorizeモジュールを使用します 。
- また、独自のフォームバリデータ、Viewプラグインなどの開発も検討します。
この記事は、初心者向けに（Zend Frameworkで）初心者によって作成されたものであるため、このケースに対する批判や、アプリケーションを改善するためのヒントは大歓迎です。
Githubでプロジェクトコードを見つけることができます： github.com/romka/zend-blog-example
この記事は3つのパートに分かれています。
- 最初の（現在の）パートでは、ZendSkeletonApplicationの構造を検討します。
- 第二部では、自分のモジュールの開発（フォーム、Doctrine ORMを使用したデータベースの操作、Viewプラグインの開発） を分析します。
- 3番目の部分は、ユーザーとTwigテンプレートエンジンでの作業に専念します。
それでは始めましょう。
環境
既にWebサーバーが構成されており（ zblog.kece.ruで入手可能）、MySQLがこのプロジェクト用に空のデータベースを作成していると想定しています。 データベースを操作するためにDoctrineを使用する予定があるという事実のため、データベースはこのORMでサポートされているものであれば何でもかまいません。
ZendSkeletonApllicationのソースコードまたは私のチュートリアルが手元にあると思います。 github.com/zendframework/ZendSkeletonApplicationおよびgithub.com/romka/zend-blog-exampleで入手できます。 さらに、MVCパターンを理解し、何らかのテンプレートエンジンとフォームバリデーターの操作経験があることを前提としています。
Zend FrameworkはすばらしいComposer依存関係マネージャーを使用しますが、これもシステムにインストールする必要があります。 Composerの詳細については、 habrahabr.ru / post / 145946の記事をご覧ください 。 簡単に言えば、Composerは、PHPプロジェクトが依存する外部ライブラリを迅速かつ便利にダウンロードおよびインストールできるコマンドラインユーティリティです。 入力では、ユーティリティは、依存関係の名前とバージョンのリストを含む直感的な形式のJSONファイルを受け入れ、出力では、必要なライブラリとその依存関係をダウンロードしてインストールし、日常業務から解放します。
この記事のテキストは、Composerによって自動的に生成された外部アプリケーションまたはファイルのソースコードを指す場合があります。 これらのファイルはリポジトリにないため、このチュートリアルで開発されたアプリケーションをさらに詳しく調べるには、必要なソフトウェアを自分でインストールする必要があります。
ZendSkeletonApplication
Zend Frameworkを使用すると、アプリケーションの構造をゼロから設計および作成できますが、 ZendSkeletonApplicationプレハブを使用してシステムを調査することをお勧めします。 Composerを構成している場合は、次のコマンドを実行するだけです。
php composer.phar create-project --repository-url="http://packages.zendframework.com" -s dev zendframework/skeleton-application path/to/install
（適切に設定されていれば、 php composer.pharコマンドは単にcomposerに置き換えることができますが、記事の後半では、より普遍的なオプションとして最初のオプションを示します）
実行後、次の構造のアプリケーションを受け取ります（最も興味深いディレクトリとファイルのみを残しました）。
config/ autoload/ global.php application.config.php module/ Application/ < Application > public/ css/ img/ js/ index.php vendor/ < , Zend Framework> composer.json init_autoloader.php
これで、作成したプロジェクトを開くことができます。 私のバージョンはzblog.kece.ruで入手できます。
作成されたディレクトリとファイルを詳しく見てみましょう。
プロジェクト構造
composer.json
プロジェクトのルートにあるcomposer.jsonファイルから始めましょう。 次の形式があります。
{ "name": "zendframework/skeleton-application", "description": "Skeleton Application for ZF2", "license": "BSD-3-Clause", "keywords": [ "framework", "zf2" ], "homepage": "http:// framework.zend.com/", "require": { "php": ">=5.3.3", "zendframework/zendframework": ">2.2.0rc1" } }
このファイルは、Composerが使用するアプリケーションパラメータを設定します。 この構成の最も興味深い部分は、アプリケーションが依存する外部ライブラリのリストを含むrequireセクションです。 現在、依存関係のリストにはZend Framework 2のみがありますが、将来、Doctrine、Twigなどの依存関係をいくつか追加します。 新しい依存関係を追加したら、コンソールでコマンドを実行するだけで十分です。
php composer.phar update
Composerは必要なライブラリをダウンロードします。 すべての外部依存関係がベンダーディレクトリに追加されました。これで、その中にzendframeworkおよびcomposerディレクトリが表示されます。
ドキュメントルート
アプリケーションのdocument_rootはプロジェクトのルートではなく、 パブリックディレクトリにあります。これはindex.phpファイルのある場所です。プロジェクトへのエントリポイントであり、このディレクトリで動作するように構成する必要があるWebサーバーです。
Index.phpはいくつかの重要なタスクを実行します。その中で最も興味深いのは、外部ライブラリの接続、アプリケーション構成のロード、および起動です。
外部ライブラリを接続するために、 init_autoloader.phpファイルがプロジェクトルートから実行されます。プロジェクトルートは、 vendor / autoload.phpおよびvendor / composer / autoaload_real.phpファイルをComposerによって自動的に呼び出します。 このファイルは、Composerによってロードされる外部ライブラリの自動ロードメソッドを定義します。 したがって、モジュールのコードでZend \ View \ Model \ ViewModelの形式の名前空間を接続すると、PHPは指定された名前空間を検索するファイルを認識します。
コードの行：
Zend\Mvc\Application::init(require 'config/application.config.php')->run();
アプリケーション構成ファイルをダウンロードして起動します。 アプリケーションを初期化するプロセス（ Zend \ Mvc \ Application :: init（）メソッドを呼び出す）で、 ServiceManagerが作成されます-アプリケーションの多くの部分で使用されるキーオブジェクト。 デフォルトでは、ServiceManagerは別のキーオブジェクトであるEventManagerを作成します。 将来的には、設定でモジュールを作成するときに、モジュールが機能するために作成する必要がある他のオブジェクトをService Managerに通知します。
ServiceManagerについては後で説明しますが、今度はconfigディレクトリを詳しく見てみましょう。 このファイルにはapplication.config.phpファイルが含まれています。このファイルは、アプリケーションの構成を含む配列を返し、多くの興味深いことを伝えることができます。
モジュール配列には、含まれるモジュールのリストが含まれます。 現在、有効になっているアプリケーションモジュールは1つだけですが、将来はさらに多くのモジュールが追加されます。
module_listener_options配列には、module_pathsおよびconfig_glob_paths配列という2つの興味深い要素が含まれています。
- module_pathsは、プラグインを探す場所を示します。デフォルトでは、ベンダーディレクトリに外部依存関係とモジュールがあります。ここでは、プロジェクト用に開発されたモジュールがあります。
- Config_glob_pathsには、モジュール構成ファイルのパスマスクが含まれています。 正規表現'config / autoload / {、*。} {Global、local} .php'は、module_name。{Globalまたはlocal} .php、global.php、local.phpの形式のすべてのファイルがconfig / autoloadディレクトリからダウンロードされることを意味します。
したがって、まず設定はconfig / application.config.phpファイルからロードされ、次に設定はconfig / autoload / {、*。} {Global、local} .phpファイルからダウンロードされ、モジュールレベルで指定された設定（これについては後で説明します）。
config / autoloadに同じモジュールの2つの設定ファイルがある場合：グローバルとローカル（module_name.global.phpとmodule_name.local.php）、グローバルファイルが最初にロードされ、次にローカルファイル、つまりローカル設定が続きますグローバルなものよりも優先されます。
local.phpおよび* .local.phpファイルは、デフォルトで.gitignoreファイルに含まれています（異なるバージョン管理システムを使用している場合は、手動で例外に追加する必要があります）。現在の環境のみに対応する設定にのみ使用してください。 つまり、1つのフォームまたは別のプロジェクトを複数の異なるサイト（運用、テスト、開発サイト）で起動している場合、アプリケーションのグローバル設定には、リストされたすべてのサイトに関連するデータ、および各サイトに固有のローカル設定を保存する必要があります、データベースにアクセスするためのデータ。
アプリケーション全体のグローバル構成ファイルに加えて、各モジュールは独自の設定ファイルを持つことができます。 そのようなモジュール構成ファイルは、 application.config.phpファイル内のアクティブなモジュールのリストが定義されている順序でロードされます。 したがって、モジュール内の別のモジュールの設定をオーバーライドする場合は、このリストでモジュールを低くする必要があります。
最後の重要でまだ考慮されていないディレクトリは、モジュールディレクトリです。 このディレクトリには、アプリケーション用に開発されたモジュールが含まれます。 ZendSkeletonApplicationとともに、1つのApplicationモジュールが提供されますが、その構造を調べる前に、ServiceManagerとは何か、なぜ必要なのかを見てみましょう。
サービスマネージャー
公式ドキュメント（ http://framework.zend.com/manual/2.2/en/modules/zend.service-manager.intro.html ）は、ServiceManagerは他のオブジェクトを取得するために設計されたService Locatorパターンを実装するコンポーネントであると述べています。 つまり、これは、アプリケーション内のどこからでもService Managerに登録されたオブジェクトにアクセスできるようにするエントリポイントです。
オブジェクトは、service_managerセクションのmodule.config.php構成ファイル、またはgetServiceConfig（）メソッドのModule.phpのいずれかのServiceManagerに登録されます（例はドキュメントからコピーされます）。
<?php // a module configuration, "module/SomeModule/config/module.config.php" return array( 'service_manager' => array( 'aliases' => array( // 'SomeModule\Model\User' => 'User', ), 'factories' => array( // — , // — , FactoryInterface, // , FactoryInterface, // PHP 'User' => 'SomeModule\Service\UserFactory', 'UserForm' => function ($serviceManager) { $form = new SomeModule\Form\User(); // Retrieve a dependency from the service manager and inject it! $form->setInputFilter($serviceManager->get('UserInputFilter')); return $form; }, ), 'invokables' => array( // — , // — , . 'UserInputFiler' => 'SomeModule\InputFilter\User', ), 'services' => array( // — , // — . 'Auth' => new SomeModule\Authentication\AuthenticationService(), ), ), );
上記のいずれかのコントローラーでServiceManagerを構成したら、次の形式のコードを呼び出すことができます。
$user_form = $this->getServiceLocator()->get('UserForm');
$ user_formオブジェクトには、対応するフォームが含まれます。
次に、ZendSkeletonApplicationの一部であるApplicationモジュールに戻ります。
アプリケーションモジュール
このモジュールのディレクトリツリーは次のようになります。
config/ module.config.php language/ < *.po > src/ Application/ Controller/ IndexController.php view/ application/ index/ index.phtml error/ 404.phtml index.phtml layout/ layout.phtml Module.php
Module.phpから始めましょう。 このファイルは、3つのメソッドを持つモジュールクラスを宣言します。
- onBootstrap（）;
- getConfig（）;
- getAutoloaderConfig（）。
このモジュールのonBootstrap（）メソッドのコードは、セグメントタイプのルート（少し下のルートタイプについて）を処理します。
getAutoloaderConfig（）メソッドは、モジュールのソースコードを探す場所をフレームワークのコアに指示します。
public function getAutoloaderConfig() { return array( 'Zend\Loader\StandardAutoloader' => array( 'namespaces' => array( __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__, ), ), ); }
現在の場合、これはモジュール/アプリケーション/ src /アプリケーションディレクトリです。
getConfig（）メソッドは、モジュール設定ファイルへのパスを返します。
return include __DIR__ . '/config/module.config.php';
このファイルは、次のデータを含む設定を持つ配列を返します。
- ルーター配列の要素は、モジュールが提供するルートのリストと各ルートのコントローラーのリストを含む配列です。
- view_managerには、アプリケーションで使用されるテンプレートへのパスと、テンプレートエンジンのいくつかの追加設定が含まれています。
- service_manager-Service Managerによって初期化される必要があるオブジェクトのリスト、
- 他の多くの設定。
他のMVCフレームワークと同様に、Zend Frameworkはルート、コントローラー、アクションなどの概念を使用します。 ルートによって、ページのアドレス、コントローラー、およびアクション（ページを表示するために実行されるアクション）が決まります。 各コントローラーはクラスであり、アクションは名前nameAction（）タイプの名前を持つメソッドです。 その結果、各コントローラーには複数のアクションが含まれる場合があります。たとえば、後で作成するBlogPostController（）コントローラーには、アクションaddAction（）、editAction（）、deleteAction（）、viewAction（）、indexAction（）が含まれます。
アプリケーションモジュールの設定は、2つのルートを定義します。
return array( 'router' => array( 'routes' => array( 'home' => array( 'type' => 'Zend\Mvc\Router\Http\Literal', 'options' => array( 'route' => '/', 'defaults' => array( 'controller' => 'Application\Controller\Index', 'action' => 'index', ), ), ), 'application' => array( 'type' => 'Literal', 'options' => array( 'route' => '/application', 'defaults' => array( '__NAMESPACE__' => 'Application\Controller', 'controller' => 'Index', 'action' => 'index', ), ), 'may_terminate' => true, 'child_routes' => array( 'default' => array( 'type' => 'Segment', 'options' => array( 'route' => '/[:controller[/:action]]', 'constraints' => array( 'controller' => '[a-zA-Z][a-zA-Z0-9_-]*', 'action' => '[a-zA-Z][a-zA-Z0-9_-]*', ), 'defaults' => array( ), ), ), ), ), ), ), );
- ルート/（サイトルート、Literalと入力）の場合、Application \ Controller \ Index controllerが責任を負います。
- フォーム/アプリケーション/ [：controller [/：action]]（セグメントのタイプ）のルートの場合-引数として渡されるコントローラーとアクション、つまりモジュール内で新しいコントローラーとアクションを定義するのに十分であり、それらは記述されたアドレスですぐに利用可能になります。 このため、ルート/ここはルート/アプリケーション/インデックス/インデックスと同一です。
ルートにはいくつかのタイプがあり、その説明はドキュメントにあります： framework.zend.com/manual/2.2/en/modules/zend.mvc.routing.html
Applicationモジュールには、1つのindexAction（）アクションを持つ1つのIndexController（）コントローラーが含まれており、ウェルカムメッセージを含むページが返されます。 このページを表示するには、モジュールのビューディレクトリにあるテンプレートが使用されます。
これで、記事の最初の部分を完成させたいと思います。それが需要があることが判明した場合、残りの2つの部分を完成させて公開します。これには、独自のモジュールを開発し、ユーザーと連携するためのメカニズムを説明する例が含まれています。
upd：
記事の2番目と3番目の部分。