2009年9月26日土曜日

GWT-RPCでのAsyncCallbackの書き方考察

GWT-RPCでのクライアント側の処理プログラムの書き方は、正直気持ち悪い。

AsyncCallback callback = new AsyncCallback(){
 @Override
public void onFailure(Throwable caught) {
 results.setText("Server Response Error");
serverResponseLabel.setHTML(caught.getMessage());
}
@Override
public void onSuccess(String result) {
  results.setText(result);
}
};

RS.Method("hello", callback);

サンプルで挙がっているような書き方は、上の書いたように、関数に対応したcallback 変数を定義しているわけだが、これだと関数が増えた時にめんどうだ。どれがどの関数に対応しているのかがわからなくなってしまう。そこで、以下のような書き方にしたほうがいい。

RS.Method(nameField.getText(), new AsyncCallback() {
 public void onFailure(Throwable caught) {
 results.setText("Server Response Error");
 serverResponseLabel.setHTML(caught.getMessage());
}
@Override
public void onSuccess(String result) {
 results.setText(result);
}
});


ま、これは好みの問題かもしれないけどね。

2009年9月25日金曜日

GWTでのデータクラス設計の際の注意事項

GWT-RPCでは、データの授受を行うデータクラスを定義し、それをサービスメソッドの引数ならびに戻り値に設定することで、複数のデータをまとめて授受することができます。

その際、若干不確定情報がありますが、以下の注意が必要です。
  1. かならずPOJOにしてください
  2. com.google.gwt.user.client.rpc.IsSerializable インターフェースを実装する
  3. アノテーション等の記述はできません
  4. 定義したクラスは、かならずclientパッケージに入れてください。
2と4は重要です。2について補足しますが、例えば以下のようにします。

import com.google.gwt.user.client.rpc.IsSerializable;

public class user implements IsSerializable {

private Integer id;
private String name;

public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}


2009年9月19日土曜日

GWTとHibernateとの統合でちょっと不都合なこと

サーバー側でデータベースアクセスをするときはHibernateを使っているのだが、Hibernate用のBeanをGWTでのRPC関数の引数に利用することができない点でちょっと不満。HibernateのBeanは基本POJOなのだが、ボクはHibernateアノテーションを記述しているので、その記述のところで引っかかっている感じ。アノテーションを書いちゃうと、GWTのクライアント(つまりJavaScript)で扱える形式じゃなくなってしまうわけです。アノテーションを使わずに、マッピングをがりがりXMLで書いていけばいい気もするが、それだと面倒だし。。。

今回の話は、クライアントからの送信時のデータ形式が、テーブル構造とたまたま一致したからの話かも知れない。こういうケースはレアかな。今作っているシステムはまさにそれなので、なるべく楽したいわけだが。これだと、クラス構造が全く同じ2つのものを書いて、データをいちいち渡さないといけない。。。なんか面倒だなぁ。なるべく手間がかからないように工夫が必要な感じだ。

GWTでプログラムやっているとプログラムがたくさん増えてきた。サービスを1つ作るだけでファイルが3つできることになるからかもしれないけど、、、研究室では、ファイルのパッケージ構造のルールを決めておかないといけないねー。

2009年9月17日木曜日

GWT導入決定

先日の日誌では、Faceletを使うとか書いてましたが、急きょ逆転してGWTの導入を決定しました。GWTの存在は開発が好きな人は知っていると思いますが、これは想像以上にワクワクするフレームワークです。GWTじたいは3年くらい前から出ていましたから、今さら感もありますが、ほんと、もっと早くこれに手を出していれば、、、という後悔をすごくしています。

GWTの特徴とは、、、という話になると、「JavaでJavaScriptを生成する」という話を良く耳にしますが、そんなレベルのものではありません。これは、Webアプリケーションの考え方を根本的に覆す画期的なフレームワークと言えます。なんかべた褒めしてますが、人によって好き嫌いがある、、というか違和感を感じるかもしれません。このフレームワークの良さを理解するためには、従来の「Webアプリケーション」というものの固定観念をあっさり捨て去る必要があります。僕もこの固定観念があって、最初、GWTを触った時は、いまいちわかりにくて、メリットがわからなかったんですけどね。JavaScriptを直接描いたほうがいいんじゃない?って思ってましたし、、、今の僕には、このGWTの良さがわかってしまったので、もう、JSFとかFaceletとか、ICEFaceとかStrutsとか、、、もうどうでもよくなりました。そんなのいらないですもん。GoogleがなぜGWTなんか考えたのか、、、わかっちゃいました。

とりあえず、うちの研究室では、ウェブアプリのプロジェクトはすべてGWTに移植します。映像系のC++を触るプロジェクト以外は、すべてGWTでいきます。今、楽しくてこのGWTプログラムばかりやってます。Google万歳!

P.S
JSF、とくにFaceletについては、ひょっとするとGWTと組み合わせる余地があるかもしれないとは、ちょっと感じてますが、、まあいまのところはないですね。

2009年9月3日木曜日

Faceletsの導入を検討中

うちでは、ウェブアプリの開発には昔からJavaを利用してまして、近年はJSFフレームワークを導入しています。が、JSFっていまいち盛り上がっていない。それに、昨今のAJaxに代表されるように、ウェブアプリはクライアントサイドでのJavaScriptでの処理がメインになりつつあります。こういった動向についていくには、JSFはちと不向きなわけです。
ただ、JSF2.0になると、AJaxを意識したモデルになるとかなんとかかんとか噂されてるようですが、そういったJSFの今後の方向性に、Faceletsというのがあるようです。

で、遅ればせながら、Facelets入門にあるプログラムを試してみました。こういうのは、やっぱり実際に手を動かしてみないとわからないものですね。印象としては、
  • JSF独特のタグを利用しなくてもよい
  • テンプレート(HTML形式)を作っておいて、それに対して、動的処理を拡張できる
というのがあるようです。思想はTapestryから来ているようです。HTMLでテンプレートを作れるから、ページデザイナーには優しいのでしょう。また、Beanも特別なクラス継承を必要とするわけではないようです(これは近年の流れですね)。たぶん、この作り方だとJavaScriptとの相性もいいはず。変なタグがないですからね。そんなわけで、研究室のJSFプログラムを、Faceletに移行しようかと検討中です。ただ、動的なページの部分をどのように書くのかといったことがまだ勉強中なわけですが、おそらくJSTLを使うんだろうと思います。