YiiのCRUDウィジェットジェネレーター

車を購入するときに、Habréの記事と追加オプションに共通するコメントは何ですか？



データモデリングの観点から見ると、どちらも「ネストされた」エンティティであり、親オブジェクトから独立して重要な意味を持ちません。

Yii（ phpフレームワーク ）にはGiiがあります。これは、マウスを数回クリックするだけでデータモデルを使用して基本的なCRUDインターフェイスを作成できる組み込みのコードジェネレーターです。

「ネストされた」データオブジェクトに似たようなものを生成できるといいですね。 今-あなたは、詳細についてはキャットへようこそ。

記事の最後で最も短気な人のために、クイックスタートの手順を示します。

また、この記事に興味がある人にとっては、ビジネスアプリケーションから内部デバイスまでの側面が考慮されます。

• ビジネスケース：トピックによる投稿
  
  • メインのトピックのリスト
  • 関連する投稿のリスト
• 内部：CRUDに基づくgiiジェネレーター
  
  • Gii Generatorテンプレート
  • ウィジェットの基本クラス
  • 統合ファサードコントローラー
• クイックスタート
  
  • サポートと開発について

ビジネスケース：トピックによる投稿

おそらく、habrについてのコメントと悪い例 多くの場合、記事自体よりも有用ですが、いずれにせよ、アプリケーションを開発する際に、データモデルの特定のオブジェクトが独立したエンティティとしてユーザーにとってあまり関心がない場合がよくあります。

単純化されたビジネスタスクを検討します。さまざまなトピックでグループ化されたメッセージを公開するためのWebサイトを作成します。

サイトには次のインターフェイスが必要です。

1. メインページ-将来はさまざまなウィジェットをサポートする必要がありますが、実装の現在の段階では、ある基準でフィルターされたトピックのリストのみがあります。
2. トピックの完全なリスト-テーブル形式のトピックの完全なリスト。
3. トピックページ-トピックに関する情報とそこに公開されている投稿のリスト。

かなり標準ですよね？

データモデルを見てみましょう。



驚きもありません。 2つのクラスのモデルにビジネスロジックが含まれます。

• トピッククラス- トピックのデータ、検証、その中の投稿のリスト、およびメインページのウィジェットの条件によってフィルター処理されたトピックのリストを返す別のメソッド。
• Postクラスはデータと検証のみです。

アプリケーションは、2つのコントローラーによって提供されます。

• SiteController-標準ページ（当社、連絡先など）、承認（参照条件では必要ありませんが、何か知っています）、およびインデックス-メインページ。 なぜなら 将来、多くの異なるウィジェットを想定しています。メインページをこのコントローラに残し、ウィジェットを特定のモデルに転送しないことは理にかなっています。
• TopicControllerはアクションの標準セットです：トピックのリスト、作成、編集、表示、削除。

潜在的に、 PostControllerを生成することもできます-管理目的および/またはコードの一部をカスタムウィジェットにコピーアンドペーストしますが、この記事の範囲外です。
これまで、ほとんどのコードはgiiを使用して生成できます。これにより、開発が高速化され、リスクが軽減されます（手動コードが少ない=ミスをする可能性が低くなります）。

2つの質問が残っています。

1. メインページにトピックのフィルターされたリストを表示する方法
2. トピックごとに投稿のリストを表示する方法は？

自動発電機を使用してそれらを解決できる場合-これは確実な成果になります。

メインのトピックのリスト

サイト/インデックスアドレスが提供するメインページには、所定の基準でフィルター処理されたトピックのリストを含める必要があります。 ビジネスロジックの一部として、モデルに含まれるフィルター条件。

表示のために、いくつかの実装オプションがあります。

最初の、汚くて速い、ビューファイル（ views / site / index.php ）ですべてを正しく行うことです：

1. ActiveDataProviderを作成します。
2. トピックモデルのデータを入力します。
3. 必要なフィールドを手動で指定して、標準のListView / GridViewウィジェットを使用して表示します 。

さらに進んで、すべてをビュー/サイト/ _topic-list-widget.phpなどの別のビューファイルにパックし、メインファイルからレンダーを呼び出します。 これにより、管理性と拡張性が少し向上しますが、それでもかなり汚れています。

ほとんどの場合、すべてのルールに従って、個別の名前空間（使用しているバージョンに応じて、 アプリ\ウィジェットまたは基本テンプレートのアプリ\コンポーネント ）で、モデルごとにActiveDataProviderの作成をカプセル化し、個別に表示する個別のウィジェットを作成します提出。 残るのは、メインページからこのウィジェットを呼び出すことだけです。 このソリューションは、クラスの分解、制御性、コードの拡張性の点で最も正確です。

しかし、このウィジェットのコードはactionIndex（）の処理に関してTopicControllerコードを非常に繰り返すと感じますか？ そして、このコードを手動で書くのはとても面倒です。

このコードを自動的に生成し、完成したウィジェットを呼び出すだけの方がはるかに良いでしょう：

<?= \app\widgets\TopicControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => app\models\Topic::findBySomeSpecificCriteria() ], ]) ?> 

関連する投稿のリスト

トピック/ビューアドレスが提供するトピックを表示するページには、トピック自体に関する情報と、そこに公開されているメッセージのリストを含める必要があります。 テーブル間の関係を正しく構成すると、モデル内のトピックのメッセージのリストが自動的に取得されるため、表示の質問のみが残ります。

フィルターされたトピックのリストとの類推により、ほぼ同じオプションがあります。

1つ目は、ビューファイルのコードですべてを実行してトピックを表示することです（ views / topic / view.php ）。

1. ActiveDataProviderを作成します。
2. モデルからのデータを入力$ model-> getPosts（） ;
3. 必要なフィールドを手動で指定して、標準のListView / GridViewウィジェットを使用して表示します 。

2つ目は、このコードを別のプレゼンテーションファイル、 views / topic / _posts-list-widget.phpに分離することです。目障りにならないように-どこかで再利用すると失敗します。

3番目は本格的なウィジェットで、 actionIndex（）部分の条件付きPostControllerのコードを大部分複製しますが、手動で作成されます。

または、コードを自動的に生成し、完成したウィジェットを呼び出します。

 <?= app\widgets\PostControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => $model->getPosts(), ], ]) ?> 

内部：CRUDに基づくgiiジェネレーター

ビジネスタスクが定義され、生成されたウィジェットの要件が概説され、どのように正確に生成されるかがわかります。 GiiにはすでにCRUDコントローラー用のジェネレーターがあります。 CRUDウィジェットの場合、既存のジェネレーターに基づいて新しいジェネレーターを作成する必要があります。

開始前のドキュメントへのリンク-独自の拡張機能を作成する場合にも役立ちます。

• Yii拡張 ;
• Yii giiテンプレート ;
• Yii giiジェネレーター 。

明らかに、すべての機能はYii拡張機能にパッケージ化されています。Yii拡張機能は、コンポーザーを介してインストールされ、プロジェクトのベンダーフォルダーに入ります。

拡張機能は3つの部分で構成されます。

1. giiジェネレーターテンプレートを含むtemplates / crudディレクトリ 。
2. Controller.phpファイル-ウィジェット呼び出し用の組み込みファサードコントローラー。
3. Widget.phpファイルは、生成されたすべてのウィジェットの基本クラスです。

Gii Generatorテンプレート

拡張機能はコードを生成する必要があるため、その中心部分はGiiジェネレーターです。

最初は、拡張機能を実装するには、組み込みのCRUDコントローラジェネレータ用の独自のテンプレートを作成するだけで十分であると想定されていました。 ところで、これがディレクトリがジェネレータではなくテンプレートと呼ばれる理由です。 しかし、CRUD-Controllerジェネレーターは入力データの非常に集中的な検証を行うため、たとえば継承のためにクラスを変更するなど、多くの要件を実装できませんでした。 したがって、拡張機能にはテンプレートだけでなく、本格的なジェネレーターが含まれています。

giiジェネレーターは、次の部分で構成されています（すべてテンプレート/ crudディレクトリ内にあります）。

• デフォルトのディレクトリは、すべての魔法が発生するテンプレートです。このディレクトリの各ファイルは、プロジェクトで生成された1つのファイルに対応します。
• ファイルform.php-名前から推測できるように、これは生成パラメーター（クラス名など）を入力するためのフォームです。
• File Generator.php-フォームからデータを受け取って検証し、テンプレートファイルを順番に呼び出して結果を作成する生成オーケストラ。

Generator.phpおよびform.phpファイルには、主にCRUDジェネレーターからの元のファイルと比較して、ファイル名、検証、説明、およびツールチップテキストなどの表面的な変更が含まれています。

テンプレートファイルは、生成されたビューとウィジェットコード自体を担当します。 まず、ファイルテンプレート/ crud / default / controller.phpが重要です。これは、元のジェネレーターのコントローラークラスに対応するウィジェットクラスを直接生成する役割を果たします。

ウィジェットはCRUDコントローラーと同じアクションを持つ必要がありますが、生成方法が少し異なります。 以下の例は、コメント付きの生成結果を示しています。

• actionIndex-すべてのモデルの無条件の出力の代わりに、メソッドは$クエリパラメーターを受け入れます。
  
  

   public function actionIndex($query) { $dataProvider = new ActiveDataProvider([ 'query' => $query, ]); return $this->render('index', [ 'dataProvider' => $dataProvider, ]); } 

• actionCreateおよびactionUpdate-成功の場合、リダイレクトの代わりに、単に成功コードを返すだけで、組み込みのファサードコントローラーによってさらなる処理が提供されます。
  
  

   public function actionCreate() { $model = new Post(); if ($model->load(Yii::$app->request->post()) && $model->save()) { return 'success'; } return $this->render('create', [ 'model' => $model, ]); } 

  
  
• actionDelete-削除ウィジェット（デフォルトでは1つのボタン）を表示するGETメソッドと、アクションを実行するためのPOSTをサポートします。 成功した場合、リダイレクトも実行しませんが、コードを返します。
  
  

   public function actionDelete($id) { $model = $this->findModel($id); if (Yii::$app->request->method == 'GET') { return $this->render('delete', [ 'model' => $model, ]); } else { $model->delete(); return 'success'; } } 

最後に、ビューファイルには次の基本的な編集が含まれます。

• h1ではなくh2に変換されるすべてのヘッダー。
• ページのタイトルとパンくずリストの表示を担当するコードを削除しました-ウィジェットはこれらに影響を与えません。
• モデルの作成と編集は、モーダルウィンドウ（ビルトインモーダルウィジェット）を使用して行われます。
• 削除ウィジェットテンプレートを追加-大きな赤いボタンが1つあります。

ウィジェットの基本クラス

ジェネレーターが作業を完了すると、アプリケーションの名前空間にウィジェットクラスが作成されます。 継承チェーンは次のようになります。アプリケーション用に生成されたウィジェットは、ベース拡張ウィジェットclass \ ianikanov \ wce \ Widgetから継承され、次に、ベースYiiウィジェットclass \ yii \ base \ Widgetから継承されます。

拡張ウィジェットの基本クラスは、次のタスクを解決します。

1. 2つの主要なフィールドを定義します：$ actionおよび$ params。これらを介して、呼び出しビューからウィジェットに制御が転送されます。
2. 生成されたクラスでオーバーライドできる多数の標準パラメーターを定義します。たとえば、ウィジェットのビューファイルへのパス、ファサードコントローラーへの名前とパス（以下について）、エラーメッセージなどです。
3. ビューをレンダリングするときの標準パラメーターを定義します：renderおよびrenderFile;
4. AccessControlやVerbFilterなどの標準フィルターが機能するように、コントローラーインフラストラクチャに類似したイベントインフラストラクチャを提供します。
5. これらすべてを一緒に収集するrunメソッドを定義します。

統合ファサードコントローラー

これらのデータの表示に問題はありません-ウィジェットはこの目的のためのものです。 しかし、編集には、誰が言っても、コントローラーが必要です。 ウィジェットごとに固有のコントローラーを生成します-その本質はすべて失われます。 標準のCRUDを使用することは必ずしも適切ではないため、GIIの追加起動に依存したくありません。 したがって、このオプションは、汎用の統合コントローラーファサードで使用されました。

このコントローラーは、構成ファイルを介してアプリケーションマップに登録され、次のアクションを実行するactionIndexという1つのメソッドのみが含まれています。

1. クライアントからのリクエストを受け入れます。
2. 制御を対応するウィジェットクラスに転送します。
3. ウィジェットの結果としてのビジネスエラーを処理します。
4. メインアプリケーションにリダイレクトします。

おそらく、このコントローラーがしていないことを示すことがより重要です：

1. アクセスレベルはチェックしません-このロジックは特定のウィジェットに属します。
2. 入力操作は実行されません。パラメーターはそのままウィジェットに渡されます。
3. 定義済みの成功コードを確認する場合を除き、出力を操作しません。

このアプローチにより、ファサードの汎用性を維持し、セキュリティ要件やアプリケーションアプリケーションコードなどのビジネス要件の実装を残すことができます。

クイックスタート

ビジネス上の課題は明確で、開始する準備はできていますか？ 拡張機能の使用には4つの手順があります。

1. インストール;
2. 構成;
3. 世代;
4. アプリケーション。

拡張機能のインストールは、composerを使用して行われます。

 php composer.phar require --prefer-dist ianikanov/yii2-wce "dev-master" 

次に、アプリケーション構成ファイルにいくつかの変更を加える必要があります。

まず、参照をgiiジェネレーターに追加します。

 if (YII_ENV_DEV) { $config['modules']['gii'] = [ 'class' => 'yii\gii\Module', 'allowedIPs' => ['127.0.0.1', '::1', '192.168.0.*', '192.168.178.20'], 'generators' => [ //here 'widgetCrud' => [ 'class' => '\ianikanov\wce\templates\crud\Generator', 'templates' => [ 'WCE' => '@vendor/ianikanov/yii2-wce/templates/crud/default', // template name ], ], ], ]; } 

次に、統合されたファサードコントローラーをマップに追加します。

 $config = [ ... 'controllerMap' => [ 'wce-embed' => '\ianikanov\wce\Controller', ], ... ]; 

これでインストールと設定が完了しました。

ウィジェットを生成するには：

1. giiを開きます。
2. 「CRUD Controller Widget」を選択します;
3. フォームフィールドに入力します。
4. コードを表示して生成します。

さらに、ウィジェットを使用するには、アクションとパラメーターを指定して呼び出す必要があります-コントローラーが呼び出されるのとほぼ同じです。

モデルのリストを表示するためのウィジェット：

 <?= app\widgets\PostControllerWidget::widget([ 'action' => 'index', 'params' => [ 'query' => $otherModel->getPosts(), ], ]) ?> 

1つのモデルを表示するためのウィジェット：

 <?= app\widgets\PostControllerWidget::widget(['action' => 'view', 'params' => ['id' => $post_id]]) ?> 

モデル作成ウィジェット（ボタン+フォームをModalでラップ）：

 <?= app\widgets\PostControllerWidget::widget(['action' => 'create']) ?> 

モデル変更ウィジェット（ボタン+フォームをモーダルでラップ）：

 <?= app\widgets\PostControllerWidget::widget(['action' => 'update', 'params'=>['id' => $post_id]]) ?> 

モデル削除ウィジェット（ボタン）：

 <?= app\widgets\PostControllerWidget::widget(['action' => 'delete', 'params'=>['id' => $post_id]]) ?> 

ウィジェットとすべてのビューのコードはアプリケーションに属し、簡単に変更することができます-すべてがコントローラーを生成するときとまったく同じです。

サポートと開発について

拡張がどのようにサポートおよび開発されるかについてのいくつかの言葉。 私は主な仕事と私の「サイド」プロジェクト（ペットプロジェクト）をいくつか持っています。 したがって、この拡張機能は私のサイドプロジェクトからのサイドプロジェクトであるため、プロジェクトのニーズに合わせて拡張機能を開発します。

オープンソースの最良の伝統では、コードはgithubで利用できます。バグの修正に関してはサポートします。また、プルリクエストを送信したい人がいる場合はタイムリーなレビューを行うようにします。