アプリケーションを作成する準備
まず、クイズアプリケーションをこちらからダウンロードしてください。このクイズアプリケーションは前回までに利用していた開発環境で動作します。また、このアプリケーションには第2回で取り上げたHelloWorldアプリケーションもそのまま入れてあります。
次に、上記ZIPファイルをインポートします。Flex Builderの［ファイル］メニューから［インポート］→［Flexプロジェクト］を選択し、ZIPファイルをインポートします。この段階ではアプリケーションはTomcatにディプロイされていませんので、AtmarkitQuizAppBlazeDSプロジェクトを右クリックし、［Tomcatプロジェクト］→［コンテキスト定義を更新］をクリックします。
jdbc.diconファイルの書き換え
次に、筆者の環境依存の設定を修正します。jdbc.diconファイルでのH2データベースのパスを、以下のように書き換えてください（.diconファイルについて後述）。ファイルはsrc/main/resourecesにあり、その40行目に書き換える設定があります。
C:/Users/fukuda.tomonari/Documents/FLEXBU~3/AtmarkitQuizAppBlazeDS/data/demo
上記はWindows Vistaでのパスの書き方なので、ほかのOSの環境の方は適宜書き換えてください。
Flexサーバのルートフォルダの書き換え
AtmarkitQuizAppBlazeDSプロジェクトを右クリックし、Flexサーバの設定画面を開いて、ルートフォルダの場所を修正してください。このプロジェクトはFlexプロジェクトとJavaプロジェクトが一体化しているので、AtmarkitQuizAppBlazeDSプロジェクトの場所を指定します。
これでクイズアプリケーションが動作すると思いますので、Flex Builder上部の猫マークでTomcatを起動してから、［実行］→［AtmarkitQuizAppBlazeDSのデバッグ］をクリックし、クイズアプリケーションを実行してください。見た目も動作も前回のままのクイズアプリケーションが動くと思います。
Flexクライアントの修正と前回の復習
それでは、サンプルアプリケーションの処理を前回との変更点を中心に見ていきましょう。
QuizFormの解説から始めていきます。といっても、QuizFormの前回からの修正点は1カ所のみです。RemoteObjectタグを追加しただけです。
<mx:RemoteObject id="srvS2BlazeDS" destination="quizService"
showBusyCursor="true">
<mx:method name="getQuiz"
result="quizLogic.onGetQuizListS2BlazeDS_result(event)"
fault="quizLogic.onGetQuizListS2BlazeDS_fault(event)" />
</mx:RemoteObject>
RemoteObjectタグの指定の仕方を簡単に確認しておきます。
- idを設定
- destinationに呼び出すサーバコンポーネントを指定（先頭小文字注意）
- showBusyCursorを設定（通信時に時計状のマウスカーソルがぐるぐる回る）
- 呼び出すメソッドごとに通信完了処理、失敗処理を行うハンドラを指定
今回から記事を読む方は、前回の記事でQuizFormのほかの部分の処理に関する解説を確認しておいてください。
AMFを使ったBlazeDS（S2BlazeDS）での通信処理
次に、QuizLogicの解説に移ります。画面に関する処理を記述しています。ここでは新たにBlazeDSでの通信処理を追加しています。そのほかの処理は一切変更していません（serverType変数の値を3に変更してあります）。
オブジェクトをそのまま受け渡すAMF通信
前回のXMLでの通信と今回のオブジェクトそのままの受け渡し（AMF通信）では、データのフォーマットが異なります。
前回のXML通信の場合、データ取得後にXMLをオブジェクトに変換しており、その後画面描画処理に移っています。そのため、BlazeDSでの通信の場合、戻り値が前回のXMLからの変換後のオブジェクトと同じものがそのまま返ってくるので、今回BlazeDSでの通信処理を追加するだけで通信処理の差し替えが実現できています。
処理の実際の流れですが、onCreationCompleteHandler（初期処理）で呼ばれるgetQuizListで通信処理のタイプによる分岐処理を行っていて、今回はgetQuizListS2BlazeDSが呼ばれます。
BlazeDS（S2BlazeDS）で通信処理を行うメリット
この処理はRemoteObjectによるサーバアクセス処理の基本になっています。といってもメソッドに渡す引数を準備してメソッドを呼び出しているだけです。
private function getQuizListS2BlazeDS():void {
// DTOの準備
var requestDto:QuizRequestDto = new QuizRequestDto();
// 特に送信するデータがないので、空のまま処理を呼び出し
// リモートメソッドを呼び出す
view.srvS2BlazeDS.getQuiz(requestDto);
}
このように処理が書けることが、BlazeDSで通信処理を行う大きなメリットの1つです。クライアントアプリケーションとサーバアプリケーション間のインピーダンスミスマッチがないので、可読性の高いコードを記述でき、無駄なデータ変換処理を書く必要もありません。
このリクエスト処理の戻りである結果イベントのイベントハンドラはMXMLで指定していたので、次に結果イベント側の処理を見ていきます。
QuizLogicのサーバレスポンス処理も簡単に
先ほどのgetQuizListS2BlazeDSの結果、イベント処理onGetQuizListS2BlazeDS_resultメソッドも非常に簡単な処理になっています。
// DTOを取得
var responseDto:QuizResponseDto = event.result as QuizResponseDto;
// 結果を取得
var quizListFromServer:Array = responseDto.quizList.toArray();
var commentListFromServer:Array = responseDto.commentList.toArray();
// エスケープ文字を削除する
removeEscapeFromQuizList(quizListFromServer);
removeEscapeFromCommentList(commentListFromServer);
// アプリケーションの初期化
initApp();
今回は前回の通信処理と異なり、1回の通信でクイズの設問と成績発表時のコメントデータを取得していて、そのすべてがレスポンスDTO（Data Transfer Object）であるQuizResponseDtoクラスのインスタンスに格納されています。データ取得後の「アプリケーションの初期化」処理は前回の記事のStruts版と共通になります。
ところで、なぜFlex側のオブジェクトとJava側のオブジェクトがそのままの形で受け渡されているのでしょうか？ これは、相互変換を実現するおまじないをFlex側のオブジェクトに行っていることにより実現されています。
メタデータタグでFlex側のエンティティ定義
ここでは、ポイントとなるQuizエンティティとQuizResponseDtoを確認しておきます。
[Bindable]
[RemoteClass(alias="jp.co.atmarkit.quiz.entity.Quiz")]
/**
* クイズテーブルに対応したエンティティ
*/
public class Quiz {
/** 問題 */
public var question:String;
Flex側のエンティティを定義する際のポイントは2点です。
- クラス定義に[Bindable]メタデータタグを付ける
- クラス定義に[RemoteClass]メタデータタグを付け、対応するJavaクラスの完全限定名を指定
- 完全限定名：パッケージ名＋クラス名
「メタデータタグ」とは？
この「メタデータタグ」はJavaでのアノテーション同様に、定義するとそのクラスや変数、メソッドに特定のさまざまな機能を自動的に付加するものです。この2点のおまじないをエンティティに施しておくことにより、Flex側オブジェクトとJava側オブジェクトの相互変換が行われます。
このおまじないは、Comment、QuizRequestDto、QuizResponseDtoでも同様に定義されています。また、それぞれに指定する完全限定名はFlexとJava双方でパッケージ構造を同じにしてあるので、簡単に指定可能です。
次ページででは引き続き、エンティティがJava側ではどうなっているのかについて解説し、「クラス読み込みクラス」やSeasarアプリケーションの設定ファイル「dicon」についても説明します。
Copyright © ITmedia, Inc. All Rights Reserved.