Java Archive

前回記事にしてからだいぶ時間が立ってしまった。。。
結局RoutingFilterの拡張＆タグリブの拡張で対処した。

RoutingFilterにおいて、設定されたパスで来たリクエストはパスの変換をしてフォワードし、そのあとで従来のRoutingFilterの処理を通すようにした。
ついでに、どのパスで来たかはrequestに保存しておいて、Actionのフィールドに自動セットするようにした。

前回のURLのイメージだと

1. “/book/search/” というリクエストが来る
2. bookという文字列をrequestに保存し、/search/にフォワード
3. “/search/” でFilterに来たら、従来のRoutingFilterの処理を実行
4. requestに保存されているパラメーターをActionのフィールドにセット
おまけ：jspにおいては、タグリブで自動的にbookというURLを補完できるような機能を追加

こんな感じ。

これで、”/book/search/” できても “/stationery/search/” できても同じActionが動いてbookやsearchをパラメーター的に扱えるようになった。

どれくらい使うシーンがあるか分からないけどね。
カテゴリー毎にURLの頭の方で分類するけどActionは同じ、都道府県毎に分類するページだけどActionは同じ、なんていう感じで多少はニーズがあるかな？

SAStrutsにおけるURLは、Actionのパッケージとクラス名によって基本的に決まる。
綺麗なURL(パラメータをURLのpathに含めたり･･･など)を作りたいときはurlPatternを利用することになる。

で、今回悩んでいるのはこんなこと。
お尻にくっつくパラメーターではなく、大分類みたいなものでURLを分けたいときはどうすればよいか？
大分類を、URLの頭のほうに持っていけるのか？

例えばショッピングサイトを作るとする。
そのサイトでは、本と文房具を売っているとする。

例えばこんな感じのURLにしたいとする。

• / -> サイトのトップページ
• /book/ -> 本カテゴリーのトップ
• /book/feature/ -> 特集ページ
• /book/search/ -> 検索
• /book/search/result/ -> 検索結果
• /book/item/{id}/ -> 商品ページ
• /stationery/ -> 文具カテゴリーのトップ
• /stationery/feature/ -> 特集ページ
• /stationery/search/ -> 検索
• /stationery/search/result/ -> 検索結果
• /stationery/item/{id}/ -> 商品ページ
• /cart/ -> カートの中身

Actionは、FeatureActionとかSearchActionとか作るんだろうけど、URLの第一階層のカテゴリーをうまく扱えない。

「/feature/book/」「/search/book/」でいいじゃないかとも思うけど、パンくずとURLがずれるよね。
気にするなという人もいるだろうけどさ。

もしこのURLを実現するとなるとぱっと思いつく案は4つ。
（そもそもできるのかとか、どうやってやるとかは考えずぱっと思いついた案を出しただけ）

1. コンテキストごと分けてしまう
2. mod_rewrite、もしくはそれに準じるようなものでごにょごにょがんばる
3. RoutingFilterかRequestProcessorあたりを拡張してがんばる
4. フォワード専用のActionを作ってがんばる

1番目はいくらなんでもメモリの無駄遣い過ぎるし、カテゴリに変更が入るたびにインフラに近い部分で設定が変わるのはいけてない。
2番目はメンテできなくなりそうだし、3番目はSAStruts本体の動きを変更することになるから微妙･･･。
4番目は、これはこれでメンテできなったり、カオスになりそう。

素直にあきらめたほうがいいのかも？

こうやって考えると、DjangoのURLの仕組みは単純で秀逸だなーと思う。

[Seasar]S2JDBCで結合してページング - 新・たけぞう瀕死の日記

以前、MLにも流れていたのですが、Oracle利用時にS2JDBCの流れるようなインターフェースで複数テーブルを結合し、ページングしようとするとエラーになります（Oracle以外のDBでは試してないのでどうなるのかわかりません）。

http://ml.seasar.org/archives/seasar-user/2008-May/014443.html

MLに投げたときはまだのんびりしてたんだけど、そろそろ対応をお願いしたいなー。
実案件への投入も見えてきてるし。

自分で行を読み飛ばすのはコストが高すぎるし、簡単なSQLまで外出しにするのもなー。

というわけでよろしくお願いします。

※2008/07/04追記
http://ml.seasar.org/archives/seasar-user/2008-July/014879.html
直った。
ありがとうございました！！

Actionが肥大化していったときに、メソッド名とパラメータ名でかぶっているものがあったみたい。

知ってる人にとっては当たり前の凡ミスなんだろうけど、一定以上の人数を集めて開発しようとしたときは気をつけないとなー。

※追記
ついでにもうひとつボタン名とメソッドが紐つかないケース。
HogeActionを呼ぶときのURLの最後は
「･･･/hoge/」
になるが、通常最後のスラッシュを省略でき、その場合indexメソッドが呼ばれる。
つまり以下のように
「･･･/hoge」
でも同じようにindexメソッドを呼び出すことができる。

しかし、もしボタン名によって呼び出すメソッドを変更したいとき
「<form action="･･･/hoge" method="post">」
のように最後のスラッシュが抜けていると、ボタン名のメソッドではなくindexメソッドが呼ばれてしまいうまく動かない。

s:formを利用していれば、自動的に最後のスラッシュを保管してくれるので問題ないが、JavaScriptからformのaction属性をいじったりするときなどは特に注意が必要。

どうやらrequestScopeからとれるらしい。
試してみたら実際に取得できて、よかったよかった。
HttpServletRequestからはとれないけど、requestScopeからはとれるというのが理屈は分かるが客観的に見ると不思議な感じ。

[SAStruts] 参照しようとしたURLを保持する
ちなみに、リクエストされたURIを取得するのって認証系の処理で一番使うと思うが、やっぱりServletコンテナの認証機能よりも自分で作った方がいいと思う。
例えば、「ログイン失敗回数をカウントしてアカウントロックを行う」とか、「パスワードが一定期間以上だったらパスワード変更を行わせる」とか、「ログインした会員の状態に応じてログイン後の画面を出し分ける」とか認証に密接に関連したビジネスロジックってあるとおもう。

それらをServletコンテナの認証と、AOPやフィルタなどとに処理が分散させてしまうのは見通しが悪い気がする。

ついでに、tomcat6のJDBCRealmのソースを見たときに、コネクション周りの処理を直さなきゃって書いてあったよ。さすがにこれは一定以上の規模だったら怖くて使えないよなー。自分で直せって意見ももちろんあるだろうけどね。

メソッドやフィールドをprivateにする名目上の意味、テキストに書いてあるような字面は分かる。
でも腹に落ちない。

privateにした上で、getterやsetterを用意するのは更に腹に落ちない。

PythonやってSAStruts触って・・・だからなのか。
自分でたくさんコンポーネントを開発していないからなのか。

うーん。

SAStrutsで自分のURLはどうやって取得すればいいんだ？
ログイン遷移のときだけじゃなくって他にも欲しいときがありそうだけどなー。

ここに書いてあるようにrequest#getServletPathとかrequest#getQueryStringとかから再構築するしかないのかな？
http://d.hatena.ne.jp/sugimotokazuya/20080314

追記
解決しました。
[SAStruts]参照URLの取得

仕事でJavaを触りだした。
恥ずかしながら今までJavaをまじめに触ったことがなかったのだけど、SAStruts＋S2JDBCということでまだ楽しくできそうかな。

で、初心者なりの雑感。
複雑だったり深いことには踏み込まず、表面をなぞって文句が多いのが初心者クオリティ。
とりとめないけど、自分の回顧録としても役立つかなーと。

Javaについて

• なんでこんなにめんどくさいんだろう
• ファイル読むだけでなんでこんなに書くの？
• Interfaceとかabstructってなんで必要なのか分からなかったけど、静的型だったら必要なの分かる
• 面倒だけど、拡張性とか柔軟性とか色々考えて設計したらこうなったんだろうなー。
• J2EEとか馬鹿じゃないのと思うけど、エンタープライズの要件をカバーしようとどっぷり考えてたらこうなるのかなー。
• Eclipceはいいけど、vimっぽいエディタを使いたいなー
• ていうか、IDEが無いとまともに開発できないってどういうこと？
• メソッド名がやたら長いのは腹が立つ
• 昔のイメージほど悪くない
• Generic型とかアノテーションとかDIとか、いいよね、クロージャは欲しいけど

SAStrutsについて

• Hot Deploy、LLやってる人からすると普通なんだろうけどやっぱり必要だよね
• Djangoと比べるのは違う気がするけど、見通しのよさは欠けるなー
• submitボタンのname属性で呼ばれるメソッドが決定されるのは便利
• プロパティーにデータが入るのは便利だが、Djangoのnewformsのようにコントロールしやすい方が好み
• さくさく開発できる感覚はいい、Javaじゃない感じ
• 逆に、これ以外ののJava開発ができなくなりそう。。。

S2JDBCについて

• DBを知ってれば、RailsとかDjangoとかそういうのよりも分かりやすいかも
• SQLファイルの取り扱いも気が利いている
• ORマッパー使うより直接SQL書いた方がいろいろいいことあるじゃん、と思っていた時期もある私にはいいかも。