S2Strutsでよくある(かもしれない)光景
たんに自分がわかってないだけだけれど
InitActionに行ったら戻れない
一覧から詳細画面にいくとき、一覧画面のgoDetail()みたいなメソッドから遷移先のJSP/mayaaにフォワードして、そこで<s2struts:init>
でInitAction#initialize()
を読んだりなんかする。いろんな責務の切り分けを考えるとこの方式はすこぶる正解なんだけど、唯一難点になるのが、すでにmayaaのほうのレンダリングを始めていたりすると、今更input(一覧画面)に戻ろうとしても遅いということ。
→inputに戻したいチェックは一覧画面のgoDetail()のほうでやろう
このボタンとこのボタンでは、違うバリデーションをかけたいのにできない!
お勧めパターンだと、あるhtmlからサブミットした内容はそのページに対応するPageに送ると。
でもそうすると、1個のページにいろんなボタンがあっても、Pageにバリデーションをつけると、本当なボタンに応じてバリデーションを変えたくても、どのボタンでもみんなおんなじバリデーションが効いちゃう。<s2struts:submit>
タグのcancel
属性を使うと、バリデーションが本当にゼンオフになってしまう。
→これは手動でバリデーションを行うか、それとも複数ボタンによって別々なバリデーションをしなくてすむような画面設計にしよう。 (とするしかないのかな。)
以前に@ValidWhen
を作ってみたけど、うまくいかなかった記憶がある。いや不要だったからやめたのかな。(TODO:なんだったか思い出す)。SAStrutsだと@Required(target = "実行メソッド")
とか書けるってことは、S2Strutsでもなんかやりようはあったはずなんだけど。
env.txtはproduct
問題がおきたときの切り分けとかを考えると、私の環境ではenv.txtはproductにするのが結局一番楽。で、都度Tomcat Launcherを上げ下ろししたほうが便利でした。たぶんctとかが効果的な局面もあるんだろうけど、謎の振る舞いを色々分析するよりは、空気を読まずにオーソドックスな開発をしたほうがいいケースが多そうな気がした
S2StrutsでSeasar2.4だともれなくStruts1.3がついてくる
S2StrutsはS2Container2.4との組み合わせだとS2Struts1.3系を使うことになる。そうすると実はStrutsのバージョンも1.3.8?になる。1.3.8では何も変わってないのかというと、<html:form>
タグの実装が変わっているので、カスタマイズしている場合は修正が必要になる。
でSeasar2.4にする必要があるかという点だけど、SMART deployを使いたい場合は2.4。だけどことS2Strutsに関する限り、個人的にはSMART deployを使いたいという強い動機はない。
あと、S2Chronosとかそのへんのプロダクトは多分Seasar2.4前提になるので、そうするとどうしてもS2Struts1.3のほうがよいという結論になる。
あ、実際私たちは開発者4名くらいの規模でS2Struts1.3を使っていて、今のところ快調に動いておりますよ。
今回はお膳立てはしたけど、自分はほとんどコードを書いてないので、それで回るかちょっと心配もあったが、さすがに枯れているだけあって、お勧めパターンでほぼ問題ないみたい。