Hatena::ブログ(Diary)

public static void main

誰かが困って検索したときに助けになる話題を書いていければと思っています。

2009-03-12

[][]第二回Wicket勉強会で発表してきた『Wicketアプリケーションを Webで公開する前にやっておく 3つのこと』

第二回Wicket勉強会で発表してきました。

内容はそのままpptをあげようかと思ったのですが、ソースコードの部分が少しあってその辺が見づらかったので記事に書き直しました。pptでの発表だとどうしてもソースコードを見せるのが難しいので、何か対策を考えたいですね。

以下発表内容と感想と宣伝です。

Wicketアプリケーションを Webで公開する前にやっておく 3つのこと

WicketでWebに公開する
  • Wicketは面白いフレームワーク
  • でも、ステートフルなために公開する際にやっておいたほうがよいことがいくつかある
  • 実際にサイトを公開して見てやっておいたほうがよさそうと思ったことを3つ紹介
  • 今回の使用するバージョンはWicket1.3.5
1. エラーページを変更する

f:id:Kishi:20090312151124j:image

  • Wicketでの開発で頻繁に遭遇するPage Expired
    • サーバ上からPageのインスタンスが消えてしまった後にアクセスすると発生
    • デフォルトではWicketの標準のPageExpiredErrorPageが表示される
  • 自前でExpredPageクラスを作る
    • 方法1.PageExpiredErrorPageを継承したクラスを作ってhtmlを変更する
    • 方法2. 自分でWebPageクラスを継承したPageクラスを作って、コンストラクタでステータスコードを設定
public class MyExpiredErrorPage extends WebPage {
	public MyExpiredErrorPage(){
		((WebResponse)getResponse()).getHttpServletResponse().setStatus(400);
	}
}
  • 表示されるExpiredPageクラスの変更
    • WebApplicationクラスを継承したクラスのinitメソッド内で変更
@Override
protected void init() {
	getApplicationSettings().setPageExpiredErrorPage(MyExpiredErrorPage.class);
}
    • ちなみにInternalErrorPageの場合
@Override
protected void init() {
	getApplicationSettings().setInternalErrorPage(MyInternalErrorPage.class);
}
2. robots.txt
  • Wicketがステートフルであることの弊害
  • robots.txtを置く
    • クローラにアクセスしてほしくないページを定義するもの
    • ドメイン直下にrobots.txtファイルを置いておくとクローラがここをまず読んでくれる
    • 重い処理をするところや半無限に生成されるページなどには書いておくとよい
  • 実際の記述
User-Agent: *
Allow: /
Disallow: /?wicket*
    • こうすることで一時生成されるWicketのURLであるhttp:localhost:8080/?wicket〜のページをクローラがインデックスしなくなる
  • robots.txt問題点
    • robots.txtはあくまで紳士協定→無視するクローラも存在する
    • 正確な記述方法が規定されていない→解釈が各社で異なる
    • 今回の書き方は多くのクローラでうまく解釈してくれている
  • 個人的には
public class WicketApplication extends WebApplication{
	@Override
	protected void init() {
		mount(new HybridUrlCodingStrategy("/login", LoginPage.class));
	}
}
3. jsessionid対策
  • Wicketアプリの初回アクセス時
  • 対策1 getClientInfoメソッド
    • Wicket-jaのメーリングリストで似たような質問があったとき、getClientInfoメソッドを使えばよいという回答
    • WebSessionを継承したクラスのコンストラクタなどで使うとよさそう
    • これを使うと利用者のブラウザの情報を取得するのに初回アクセス時にページの再読み込みが発生し、JSESSIONIDが消える
  • 対策1の問題点
    • デフォルトで表示されるBrowserInfoPageクラスがrefleshを使っているが、クローラは解釈できない
    • クローラがページにアクセスできない = GoogleやYahooにインデックスされない
  • 対策2 自前のLinkクラスを作る
public class MyLink extends BookmarkablePageLink{
	//コンストラクタも適当に書いてください
	@Override
	protected CharSequence getURL() {
		String url = super.getURL().toString()
			.replaceAll(";jsessionid=[^\\?]+", "");
		return url;
	}
}
    • Linkを使うときには常にこのクラスを使う
  • 対策2の問題点
    • CookieをサポートしていないDoCoMoのブラウザなどでログインできなくなる
終わりに
  • 今回話した内容が参考になれば幸いです。


今回の勉強会の感想

今回はメモを取っていないので大雑把な感想を。

80人の参加者の勉強会で参加率も高かったので部屋がいっぱいでした。

前回もLTをやりましたが、これだけ人数が多いと少し緊張しますねw自分の今回の話は反応がいまいちだったので次回話す機会があったら内容の路線を変更しようかと思っています。

第一回目はWicketの運用の話が多かったですが、今回はJavaScriptに関する話が多かったです。発表内でも触れられていましたが、クライアント側で動的に変化する需要が増えているようですので、その辺もカバーしているところがWicketが注目されている理由のひとつかもしれません。とはいえ指摘があったように、結局JavaでJSを薄くラッピングしているだけなのでちゃんとやろうと思ったらJavaScriptの知識が必要になるのですが。

id:NAGASEYASUHiTOさんのComponentInstantiationListenerを使う話が個人的には一番参考になりました。自分では使ったことがないのですが、いろいろとできることの幅が広がりそうです。

あとグリーパネェと書くのが礼儀らしいので書いておきますね。会場を貸していただいてありがとうございました。



懇親会の感想

かなり人数がいたので場所の確保や参加者の把握がすごく大変だったと思うのですが、id:Yamashiro0217さんの幹事力が光りましたね。

Wicketの話もいろいろできてよかったのですが、ORMの話やLuceneの話もできてよかったです。ORMにiBatisを使っている方が何人かいらっしゃったのですが、皆さん基本的なSQLは自動生成してらっしゃるそうで、自分だけじゃなくて安心しましたwこういう場でLuceneの話ができたのも初めてなので新鮮でした。

id:bose999さんにJBossをプッシュされたので、早速手元の開発で5.0.1.GAを試してみています(といっても今のところ普通にTomcatを使うのと違いない使い方ですが)。

途中で眠気が限界が来たので始発で帰ったのですが、二次会では濃い話が聞けて面白かったです。



【宣伝】Wicket本発売日決定

ページで告知されていますが、明日3月13日にid:t_yanoさんの書いたWicket本が発売されるようです。初のWicketを扱った和書ですので、これでもっと国内でWicketが盛り上がるとよいですね。

タイトルが告知されているものとAmazonのとで違いますがどっちが正しいんでしょうかね。

現在実家に帰っている最中なので本を読むのは当分先になりそうです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/Kishi/20090312/1236841942