サンプルアプリ3 - ひがやすを技術ブログ

doFindEmployee()メソッドの記述からするつもりでしたが､Teedaで画面が表示されるとき､あるいは、サブミットされたときの処理の流れを簡単に説明しておきたいと思います。
画面が表示されるときの流れは次のとおりです。

入力内容がリクエストに復元される。
リクエストからPageに値がセットされる。
Pageのinitialize()メソッドが呼び出される。
JSFのコンポーネントが画面を表示。

1は説明が必要ですね。Teedaでは、P(ost)R(edirect)G(et)パターンで基本的に動くようになっています。どういうことかというと、サブミット(POST)されたときに、Pageの内容がDB(Sessionを使うことも可能)に保存され､次のPageにredirectされます。するとブラウザは､次のPageをGetで呼び出します。そのときにTeedaは、先ほどDBに保存した内容をリクエストに復元します。Seasar2のexternalBindingの機能により､リクエストの内容は､自動的にPageにセットされます。このようにして、Page間で値が引き継がれます。これは、開発者にとって透明(裏で自動的に行われます)です。
例えば､EmployeeSearchPage.javaでnameとdepartmentIdに入力された内容を格納する場合､次のEmployeeListPage.javaにnameとdepartmentIdのプロパティを作っておけば､自動的に入力された内容を受け取ることができます。
サブミットされたときの流れは次のとおりです。

入力した内容がPageにセットされる。
submitタグのidがdoXxxのように、doではじまっていれば､Page#doXxx()のメソッドを呼び出す。
submitタグのidがgoXxxのように、goではじまっていれば､何もしない(ページ遷移のみ)。
ページの内容をDBに保存する。
XXXに定義されている@Navigationの情報を元に次の画面にredirectする。

@Navigationは、次のような感じで指定します



@Navigation(to=XxxPage.class)

public static final String XXX = "Xxx";

goXxxのときは、これだけでいいのですが､doXxxの時は､メソッドで処理を記述することができます。



public String doXxx() {

  ...

  return XXX;

}

Teedaは、Pageの内容をDBに自動的に保存しますが､Listなど大量のデータが格納されている可能性があるものがどのように扱われるか気になる方もいるでしょう。Teedaは、文字列､数値、日付、論理値など単純な型しかDBには保存しません。これがデフォルトの動きですが､アノテーションを使って明示的に指定することもできます。
さて、doFindEmployee()メソッドですが、考えてみると、このメソッドで特に何もする必要はないので､submitタグのidをgoEmployeeListに変更して、再度ソースを自動生成させます。



<form id="employeeSearchForm">

  従業員名:<input id="name" type="text"/>


  部署    :<select id="departmentId" size="2">

             <option>Please select

             <option value="1">Accounting

             <option value="2">Research

           </select>


  <input id="goEmployeeList" type="submit" value="検索"/>

</form>



public class EmployeeSearchPage {

  //@Navigation(to=EmployeeListPage.class)

  public static final String EMPLOYEELIST = "employeeList";
  private String name;

  //@SelectOneMenu(label="")

  private int departmentId;

  private List departmentIdItems;

  private DepartmentLogic departmentLogic;

  ...

  public String initialize() {

    //TODO

    departmentIdItems = departmentLogic.findAll();

    return null;

  }

}

@NavigationのtoにEmployeeListPage.classと自動的にクラスが埋め込まれています。churaはどうして次に遷移する画面のPageクラス名を知ることができたのでしょうか。
submitやanchorタグのidがgoXxxの場合､churaは次の画面のPageクラス名をXxxPageというように自動的に推測します。
それでは、初期状態のまま実行してみましょう。部署のリストには2件(モックの内容)だけ表示されていて。DBの内容が反映されていません。まだ、@SelectOneMenuの設定をしていないからです。
それでは、@SelectOneMenuのコメントをはずし､labelにnameといれて再アクセスしましょう。今度はDBの内容が反映されて4件表示されました。

churaで開発するときには､今やったように「1つ修正したら直ぐ確認(テスト)」を繰り返し行ってください。決して、一度にたくさん修正しないでください。何を修正したのか､何を確認しなければならないのかが分からなくなってしまいます。

これまでのJavaの開発では､このような小刻みな反復は現実的ではありませんでした。なぜなら、修正を反映させるためには､アプリケーションを再起動する必要があったからです。しかし、Seasar2では、HOT deployの技術によって､アプリケーションの修正を再起動無しに即座に認識できるようになりました。再起動の無駄な待ち時間が削減されただけではありません。小刻みな反復により、確実に修正の確認ができ､品質も向上するのです。
それでは、ボタンを押してみましょう。画面遷移しません。まだ、@Navigationがコメントになっているからです。@Navigationのコメントをはずしましょう。まだ、EmployeeListPage.javaが作成されていないので､コンパイルエラーになってしまいました。実は、これもchuraで開発するときの重要なポイントです。コンパイルエラーによって何をしなければいけないのかが明確になるのです。この場合は､EmployeeListPage.javaを作成しなければならないことが直ぐに分かります。