Life is Really Short, Have Your Life!!

SAStruts+S2JDBCなう

sastruts, s2jdbc, seasar

新しく自分の所の業務システムを組んでいて、色々迷った結果、SAStruts+S2JDBCの組み合わせを採用しました。Javaりたかったし。

プレゼンテーション層はSAStrutsでなくてもいいやって思うけど、S2JDBCが使いやすくてなんかもうこれ以外のO/Rマッピングツール使いたくなくなってきた。すごいなこれ。

• これJOINする必要あるんじゃね
  • Entityにマッピングかいてwhere().innerjoin("マッピング名")で5分で終わり。
• 検索条件組み立てめんどくせー
  • SimpleWhere()のチェーンが最高に使いやすいので5分で終わり
  • これが一番生産性の向上に役立ってると思う。Where句以降を流れるようなインターフェイスで実装できるのは快感。
• SQLを書きたい
  • 書いて引数をマップするだけ。メソッドは1行書いて終わり。
• ページングも楽
  • publicにしてれば値を引きついでくれるし
• 地味にデバッグ情報も充実
  • リクエストプロセッサーが吐いてくれる情報だけで事足りてる。デバッガ使うまでも無いぐらい。

PHPの場合はPHPファイルを直接編集すればプログラムに反映されるけど、Java(S2)の場合は全部タイプセーフな設計でカバーしてくれているのも大きいと思う。くだらないミスを防げている。

Cakephpもそうだけど、ページングする際に｢検索条件で検索結果取得｣と｢同等の条件でCOUNT文実行｣の2発SQL投げているみたいなんだけど、これってみんなそうやってるんだよね。limit().offset()が入ってしまえばlist.size()してもしょうがない。僕もそうやってページングしてる。

で、SAStrutsで３つばかりよくわかんない点がある。

ActionFormはActionに１つだけなのは仕様？

検索と編集でFormを分けたい衝動に駆られる。

｢仕様です｣なら別にそれでいいし、リクエスト単位で管理してるから内容がかぶるわけでもないけど、気持ち的には分けたい。そんなに強い情熱はない。

<s:form>でJS

onSubmitでJSを実行させたいんだけど、<s:form>がそんな属性ねーよって怒る。formタグのHTML書いてって話ならそれでいいや。できればそのまま使いたいけど。

clickじゃダメなのっていう話なんだけど、エンター叩いてSubmitさせることも許容したいので。

ActionFormで配列

チェックボックス一括選択→POSTさせてどーんと状態変更っていう時に、String[]の配列しか受け入れてくれなかった。Listとか使えないのかな？

<input type="checkbox" name="hoge[]" />

こんな書き方で、ActionFormにString[] hogeって書いた。Listにするとインスタンスが作れないぞっていうExceptionが出た。

チェックボックス一括選択された時の取り方でオヌヌメがあればそれに沿いたい。

ツイートする

Permalink | コメント(5) | トラックバック(1) | 21:54