Italian多くのアプリケーションはデータベースに保存されたデータに基づいており、それにアクセスするためのインターフェイスを提供します。オブジェクトに基づいたデータ操作機能を提供するモジュール作成の反復タスクを自動化します。ジェネレーターをお教えします。ジェネレーターのさまざまな可能性について説明します。多くのページはこれらの1つに還元できます。アプリケーション内部で繰り返し作られます。オペレーションを生成できるようにするための十分な情報を持ちます。ジェネレーターの機能を示します。これによって8章を思い出すでしょう。クラスを含む、ブログアプリケーションのよく知られた例です。図14-1で描かれているように、リスト14-1はスキーマを示します。データモデルの例コード生成を可能にするためにスキーマ作成の期間で従わなければならない特別なルールは存在しません。スキーマをそのまま使い、管理画面を生成するためにスキーマの属性を解釈します。tipこの章を最大限に活用するには、例で示すの内容を実際構築して試すことをおすすめします。何を生成し、生成されたコードで何が行われるのかということをより理解できるようになります。--no-confirmation生成された管理インターフェイスは、作業が楽になるようにいくつかのマジックメソッドに依存しています。メソッドを作ってください。ファイルからのモデルクラス定義に基づいて、モジュールを作成できます。モジュールだけを用いてサイト全体の管理画面を作成できます。モジュールを説明します。いう名前の特別な設定ファイルを通してモデルを解釈します。ファイルを変更できます。(レイアウト、ルーティング、カスタム設定、オートロードなど)。コードの使いかたを限定します。モジュールを設定することもできます。コマンドで管理画面をビルドします。アーキテクチャに基づいています。アクセスできます:http://localhost/backend.php/article図14-2、図14-3で描かれている生成モジュールの外見は、商用アプリケーションとしてそのまま利用できるほど十分に洗練されています。ディレクトリ内の記事の管理画面のコードは初期化だけ行われたので空に見えます。フォルダーの内容を確認することです。リスト14-2はキャッシュのなかで見つかる生成アクションとテンプレートのリストを表示します。構成されることを示します。コードを見てみると、モジュール性が非常に高く、読みやすく拡張性のあるものであることがわかります。設定ファイルで見つかるパラメーターに依存します。ファイルを開いてください。new:このコンフィギュレーションは基本的な管理画面を生成するのに十分です。キーの下に追加されます。カスタマイズした典型例を示しています。"%%title%%"このコンフィギュレーションでは、6つのセクションがあります。設定目的のためのみ存在します。つぎのセクションでこの設定ファイルで利用可能なすべてのパラメーターの詳細内容を説明します。ジェネレーターの設定ジェネレーターの設定ファイルはとても強力で、生成された管理画面を多くの方法で変更できます。全体の構文の記述が読んで学ぶには長いので、文章で説明したら、この章がこの本でもっとも長くなってしまいます。ジェネレーターのチートシートが図14-7で再現されてます。/uploads/assets/sfAdminGeneratorRefCard.pdfから保存し、この章のつぎの例を読むときにこれを頭のなかにとどめておいてください。管理モジュールを調整します。定義されるカラムです。(BlogArticleForm)。よって、どのフィールドが表示され、どれが非表示であるかを選び、オブジェクトモデルで直接対応するものがなくても独自フィールドを追加できます。ファイルのカラムごとに1つのフィールドを作ります。キーの下で、それぞれのフィールドの表示方法やフォーマット方法などを修正できます。フィールド用のラベルとツールチップを定義します。つぎのセクションでそれぞれのパラメーターが動作する方法を詳細に説明します。対するフィールドの設定をオーバーライドできます。キーの下のモジュール全体に対して設定される設定項目はビュー固有の領域でオーバーライドできます。セクションで定義したフィールドはそれぞれのビューに対して表示、隠す、順番に並べるなど、さまざまな方法で分類できます。キーはこの目的のために使われます。モジュールのフィールドを順番に並べるには、リスト14-7のコードを使います。フォームは2つのグループに集められた4つのフィールドを表示します。表示するカラムと表示される順序を選ぶために単純な配列にフィールドを置きます。値はカラムの名前で並べ替えられた配列のままです。フォームクラスに参照されるすべての必須フィールドの一覧を表示することには注意を払ってください。ないと予期せぬバリデーションエラーに遭遇するかもしれません(第10章を参照してください)。設定されたフィールドはスキーマで定義された実際のカラムに対応している必要はありません。ビューでも利用できます。メソッドで拡張できます。(ゲッターではフィールド名にキャメルケースを使っていることに注意してください)。ビュー内のカスタムフィールドパーシャルフィールドモデルに設置されたコードはプレゼンテーションから独立していなければなりません。メソッドの例はレイヤー分離の原則を順守していません。ビューコードのなかにはモデルレイヤーに現れるものがあるからです。タグとして表示されてしまうでしょう。出力するコードはパーシャルテンプレートで対応するほうがベターです。ジェネレーターによってアンダースコアのプレフィックスを持つフィールド名を宣言できます。ファイルはリスト14-12のように修正されます。パーシャルを作る必要があります。$BlogComment)。ビュー内のパーシャルフィールドレイヤー分離の原則が順守されます。この原則に慣れたら、アプリケーションのメンテナンスが容易になります。キーの下で通常のフィールドと同じ事を行います。キーの先頭に含めないでください。リスト14-14をご覧ください。}パーシャルにロジックが混在するようになったら、コンポーネントに置き換えることをおすすめします。変更することで、コンポーネントフィールドを定義できます。コンポーネントを追加カラムとして利用する。コンポーネントが呼び出されます。ビューで使うことができます。ビューの外見を変更するために、テンプレートを変更したいと思うことがあります。これらは自動的に生成されるので、生成されたテンプレートを変更するのはあまりよいアイデアではありません。設定ファイルを使うべきです。モジュール性を損なうことなく、ほとんどすべての必要なことを行えるからです。ページはカスタムページタイトルを持ちます。ビューのタイトルをカスタマイズしたい場合、リスト14-16のように行います。ビュー内のカスタムタイトルデフォルトのタイトルはクラスの名前を使うので、モデルが明白なクラスの名前を使うのであれば、これらのクラス名で十分であることはよくあります。囲まれたフィールドの名前を通してアクセスできます。内部において、表示されるフィールドを記述するための助けになるツールチップを追加できます。プロパティを追加します。結果は図14-10に示されています。オプションを使うことで同時にカスタム書式で日付を表示できます。ヘルパーと同じフォーマットパラメーターを受けとります。インターフェイスの文字列の多言語翻訳機能はsymfonyに搭載されています。(すなわち、__()ヘルパーへの呼び出しと一緒に)。ファイルにフレーズの翻訳を追加することで、生成された管理画面を簡単に翻訳できることを意味します。ビューは、表形式、もしくはすべての詳細な内容が一行に積み重ねられた状態で、レコードの詳細を表示できます。これはフィルター、ページ分割とソート機能も含みます。これらの機能は設定によって変更できます。詳細はつぎのセクションで説明します。ビュー間のハイパーリンクは主キーのカラムによって生成されます。ビューにアクセスすることを許可するハイパーリンクを提供します。プレフィックスとしてカラムの名前に追加します。フィールドにハイパーリンクを置く方法を示しています。図14-11のスクリーンショットを確認してください。ビューはフィールドがカラムとして表示されるtabularレイアウトを使います。レイアウトを使ってフィールドをテーブルの全長を詳しく記述する単独の文字列に連結することもできます。キーにリストのそれぞれの行の値を定義するパターンを組み込まなければなりません。レイヤーを定義します。結果は図14-12です。キーを使うことに留意してください。ビューにおいて、フィルターのインタラクションのセットを追加できます。これらのフィルターによって、ユーザーは結果をより少なく表示して速く望むものに到達できます。キーの下にフィルターを設定します。対して、フィルターは関連するテーブルのレコードのドロップダウンリストです。メソッドによって返されるものです。対して、フィルターはリッチな日付タグのペアで、時間の間隔を選択できるようにします。オプションを持つドロップダウンリストです。最後の値はフィルターを再初期化します。BlogArticleFormFilter)。フィルターフォームに対してカスタムクラスを定義することで、フォームフレームワークの力を活用しすべての利用可能なフィルターウィジェットを使うことでフィルターフィールドをカスタマイズできます。定義することで簡単に実現できます。フィルターを修正するためにパーシャルフィルターも使うことができます。リスト14-23はパーシャル以外のデフォルトのふるまいを模倣する実装の例を示しています。ビューにおいて、図14-18で示されるように、テーブルのヘッダーはリストを再び順番に並べるために使われるハイパーリンクです。レイアウトの両方で表示されます。パラメーターでページがリロードされます。順番を定義することも可能です。構文はリスト14-24で示された例に従います。desc]note実際のカラムに対応するフィールドだけが、ソートのコントロール機能に変換されます。カスタムもしくはパーシャルフィールドには対応していません。パジネーションをカスタマイズする生成された管理画面は大きなテーブルさえも効率的に処理します。ビューがデフォルトでパジネーションを使うからです。テーブル内の実際の行の数がページごとの行の最大数を越える場合、パジネーションのコントロール機能がリスト下部に表示されます。件に制限されています。パジネーションにより、表示される行のみがデータベースから効率的に抽出されるのでパフォーマンスが保証され、管理モジュールによって何百万行もあるテーブルを管理できるのでユーザービリティが保証されます。使ってレコードのリストを取得します。リストで関連オブジェクトを使う場合、リストを表示するために必要なデータベースクエリの数が急に増えることがあります。オブジェクトを検索するためにリスト内のそれぞれの投稿に対する追加クエリが必要です。メソッドを使うページャーを強制したい場合があるかもしれません。パラメーターで指定できます。概念についてより広範囲に説明します。ビューにおいて、ユーザーは新しいレコードもしくは渡されたレコードに対してそれぞれのカラムの値を修正できます。関連するフォームです。定義することで使うクラスをカスタマイズできます。ジェネレーター用のウィジェットとバリデーターすべてをカスタマイズできます。アプリケーションに対してデフォルトのフォームクラスが使われ特別にカスタマイズされます。設定ファイルでラベル、ヘルプメッセージ、とフォームのレイアウトを直接カスタマイズすることもできます。モジュールはこれを活用して、より自動化されたコントロール方法を提供するので、リレーションの管理作業が大いに簡略化されます。ジェネレーターによって考慮されます。テーブルとの関係を持ちます。(説明図は図14-9を再度確認)。モジュール(多対一のリレーション)内の記事に関連するコメントのリストを表示する場合も同様です。図14-16で示されるように多対多のリレーションも考慮します。モジュールはユーザーが通常のCRUDオペレーションを実行できるようにしますが、ビューに対して独自のインタラクションを追加するもしくは可能なインタラクションを制限することもできます。アクションにデフォルトでアクセスできるようになります。リスト14-27で定義されたリストのインタラクションは図14-18のようにレンダリングします。それぞれの行はレコードを編集するためのボタンとレコードを削除するためのボタン、それらに加えて、レコードの選択を削除するためにそれぞれの行の上に1つのチェックボックスを表示します。リストの一番下で、1つのボタンによって新しいレコードを作ることができます。定義するアクションのセットは1つだけです。インタラクションは図14-23のようにレンダリングされます。アクションは現在の編集をレコードに保存します。ビューを表示することです。アクションは続けざまに多くのレコードを追加するときに非常に便利なショートカットです。アクションの位置に関しては、これはほかのボタンから分離されているので、ユーザーが誤ってクリックすることはありません。対してこれらのアクションに対応するデフォルトのアイコンとアクションを使うように伝えます。ビュー内のインタラクションしかしカスタムインタラクションを追加することもできます。この場合リスト14-28で示されるように、アンダースコアで始まらない名前、と現在のモジュールのなかのターゲットのアクションを指定しなければなりません。アクションを呼び出すことが行われます。現在のオブジェクトの主キーはリクエストパラメーターに自動的に追加されます。アクションはリスト14-29のように実装できます。リクエストパラメーターのなかで選択されたレコードの主キーの配列を受けとります。あるカテゴリのためにアクションを完全に抑制したい場合、リスト14-30で示されるように、空のリストを使います。ビューで使われるフォームを自動的に考慮します。対応するフォームクラスを編集することでこのフォームをカスタマイズできます。セキュリティ機能の説明に関しては6章を参照)。パラメーターを考慮に入れます。listエントリーに対して機能します。加えて、ジェネレーターはクレデンシャルにしたがってインタラクションも隠すことができます。リスト14-31はこれらの機能のお手本を示しています。}生成モジュールのプレゼンテーションを修正する独自のスタイルシートを適用するだけでなく、デフォルトのテンプレートで上書きすることで、生成されたモジュールのプレゼンテーションが既存のグラフィカルな表にマッチするように、そのモジュールを修正できます。コードは構造化された内容を持つので、プレゼンテーションであなたが望むことを大いに行うことができます。よって提供されるメカニズムも利用できます。ビューはヘッダーとフッター部分テンプレートを系統的に含むことができます。いう名前のファイルを作ります。これは追加の設定なしで動作します。変数を通していつでも現在のページャーにアクセスできることに留意してください。フォルダーのなかでオーバーライド可能でフレームワークから継承された別の部分テンプレートが存在します。ジェネレーターのテンプレートは個別に上書きできる小さな部分に分割可能で、アクションは一つずつ変更できます。同じ方法でいくつかのモジュールに対してこれらを上書きしたいのであれば、おそらくは再利用可能なテーマを作るべきです。モジュールのなかで使えます。定義されたファイルを使います。あることに注意してください。コードを実行しないようにするために代替構文を使います。リスト14-34はデフォルトのテンプレートのテンプレートの抜粋です。テーマから始め、少しずつ修正し、こまめにテストすることです。tipジェネレーターのテーマをプラグインのパッケージにすることができるので、再利用性が高くなり、複数のアプリケーションにまたがってデプロイすることが簡単になります。詳細な情報は17章を参照してください。内部コンポーネントのセットを使います。内部コンポーネントはキャッシュ内部に生成されたアクションとテンプレート、テーマの使用、テンプレートのテンプレートの解析を自動化します。既存のジェネレーターとは似ているもしくは完全に異なる独自のジェネレーターを作るためのすべてのツールを提供することを意味します。メソッドで管理されます。クラスを例としてください。まとめバックエンドのアプリケーションを自動的に生成したい場合、基本はよく定義されたスキーマとオブジェクトモデルです。管理画面のカスタマイズによって生成されたモジュールのカスタマイズの大半は設定を通して行われます。generator.ymlファイルは生成されたバックエンドのプログラミングにおいて中心的な役割を果たします。ビューの見た目を完全にカスタマイズできます。ジェネレーターが必要な機能をネイティブにサポートしない場合、アクションをオーバーライドする部分テンプレートフィールドと機能は完全な拡張性を提供します。ジェネレーターのメカニズムへの適合方法を再利用できます。