ディレクトリ配下に、各ロケールに対応したプロパティファイルを作成します。Name)で文字列を取得します。タグを個々のページに埋め込むのは避けてください。リソースの読み込みは、フレームワークの処理として重い処理のため、個別のページでリソースを読み込むよりも、アプリケーションレベルで設定を行った方がパフォーマンスが向上します。ファイルへの設定・記載を推奨します。新たにテンプレート機能が追加されました。サイトでは共通項目(ヘッダ、フッダ、右ペイン、左ペインなど)と個別のページに特化した内容を分けて構成する事がよくあります。テンプレートを作成する事によって、個別ページの作成に専念でき、テンプレート内の特定のページを更新した場合も、他に対して1度の修正で全てに適用できるようになるため運用・保守性も大幅に向上します。ページのデザイナーと開発者の共同作業が今まで以上やりやすくなります(する事が可能です)。標準で用意されているタグを使用して画面デザインを作成していきますが、ここでは別の方法をご紹介します。コードや専用のタグに変換して実装を行っていました。コードに変換した後(もしくはその最中で)、デザインの変更を加えようとした場合に大変になる場合があります。コードを確認する事が困難だったりします。コンテナを用意しなければ、修正したデザインを確認できなくなります。コード変換した後のデザイン変更は非常に困難になります。ページのデザインを実装するようになりました。ページとして動作させる事も可能になりました。ページとして認識・表示させる事ができるようになります。タグを挿入中に、デザインの変更を加えるなど、デザイン修正に対する出戻りが発生しなくなります。ファイルの開発保守性等も高まる事が期待されます。要素を埋め込む例を示します。タグに対して挿入していきます。プログラマが記載する部分です。ページとして扱われます。参照できるように)する事で同じファイルを参照する事ができます。ファイルを配置しています。ファイルを読み込みます。ファイルを読み込む事ができます。ファイルを読み込みますので、環境に応じてパスを書き換えるなどの手間も不要となります。大幅に高まっています。実装部分にビジネスロジックを埋め込むような事(Scriptlet)はできなくなりましたので、出来上がったコードの可読性、保守性も大幅に高まります。変換する必要がないため、ある一部分のコードを修正するたびに再度コンパイルし、クラスをロードするといった、画面修正から確認までに要していた待ち時間のストレスも大幅に現象します。よる開発へと移行してください。ページで入力された情報を受け取る方法や、画面遷移方法などバックエンドで必要となる処理について紹介します。リクエスト処理のライフサイクルについて紹介します。アプリケーションを作成する上では、ここに示すライフサイクルの詳細を十分に理解していなくてもプログラムを書く事ができます。プログラムを行っている際に何らかの問題が発生した場合、どのフェーズまでプログラムが実行されているのかを把握しておく事で原因を究明しやすくなります。各フェーズの実行順を越えて何らかの処理を施したいような場合、どのフェーズからどのフェーズに移行するのか、させるのかを把握して置く事は細かな処理を行う上で重要となってきます。そこで、是非このライフサイクルの概念を理解してください。ライフサイクルの各フェーズでどのような事を行っているのかについて紹介します。復元フェーズについて紹介します。ツリーを生成(もしくは復元)します。アプリケーションの開発を行う事ができます。クラスに変換されツリー構造で扱われている事を理解しておいてください。細かな制御が必要になった場合にこのツリーを操作する事が可能です。初心者の方はこの部分は軽く流して頂いて結構ですが、本格的に使用される場合は是非理解してください。同様にツリー構造として表されます。クラス(もしくはそれを継承したサブクラス)として表現されます。インスタンスに対して保存します。ユーザから初めてリクエストがあった場合にツリーが生成され、2回目以降のリクエスト時に復元されます。操作するといっても過言ではありません。(後述:コンポーネントバインディング)。タグを生成する事も可能です。対応のコンポーネントを独自に作成する事も可能。本説明ではコンポーネントの作成に関する説明は時間の関係上割愛しています。)次に、リクエスト値の適用フェーズについて説明します。復元フェーズが終了した後、リクエスト値の適用フェーズに移行します。コンポーネントのツリー中に含まれる全コンポーネントに対して適用していくフェーズです。コンポーネントに対してリクエストされた値を適用していきます。ここに示す例のように、画面中の入力項目(inputText)に対してある値が入力された場合、新しい値がコンポーネントに対して適用されます。リクエスト値の適用フェーズが完了すると、入力値の検証フェーズへ移行します。入力値の検証フェーズでは、入力された値が妥当かどうかの検証(バリデーション)や、入力された値を変換(コンバージョン)する処理を行います。内部的に実行される順番は、データを変換(コンバージョン)した後にデータの検証(バリデーション)を行います。各子コンポーネントはコンポーネントに関連付けられた、検証(バリデーション)や変換(コンバージョン)を実行していきます。検証(バリデーション)では入力された値が、期待値に対して妥当か否かを検証します。(JSR-303)が統合されました。提供されている、アノテーションを使用して入力値を検証する事ができます。使用して独自のバリデーションを作成する事も可能です。タグでエラー内容を表示する事ができます。指定する事で個々のコンポーネント毎にエラーを表示する事ができます。使用する事もできます。設定ファイル中に下記のパラメータを設定する事で無効にする事ができます。利用して実装する方法もあります。標準で提供されているバリデータとしては下記があります。インタフェースを実装した独自のクラスを作成します。メソッドが定義されており、このメソッド内に独自のバリデーションコードを実装します。アノテーションを付加しています。このアノテーションを付加するだけで利用可能となっています。コンポーネントのタグ内で作成したバリデーションを指定します。標準で下記のコンバータを提供しています。インタフェースを実装しています。インタフェースでは下記の2つのメソッドが定義されており、独自のコンバータを実装する場合はこれらのメソッドを実装します。実際に変換を加えたい値を指定します。型に変換しており、書式が異なる場合にエラーメッセージを表示しています。入力値の変換、検証が行った後、モデル値の更新を行います。バインド(結びつけ)し、入力された情報をモデルに対して代入する作業を行います。name)に対して一致・更新させる作業を行います。操作しなくても、このモデル(POJOのJavaクラス)値に適用された値を使ってユーザからの入力データを取得したり、バックエンドの処理で利用できるようになります。入力値などを扱う際に最も便利な点です。メソッドしか存在しない場合は、書き込みだけが可能となります。メソッドを実行し、再帰的に子のコンポーネントで同様のメソッドを実行していきます。))呼び出しを行っています。CDI)に対して値を更新できる事を意味しています。して扱う事も可能です。クラスであるため、モデルとなるクラスを共通して扱う事もできます。実装においてそれぞれで実装する必要もなくなりテスト工数等も少なくする事ができます。クラスの設計上は気をつけてください。低下する場合もあります。バインディング以外のバインド方法を紹介します。対してバインドします。対してバインド(結びつけを行います)します。バインディングは何が違うのか?どういう時に使うのかという事です。バインディングはモデル値の更新フェーズ前に入力された値等を取得する事も可能です。