リダイレクトは、やっぱり processAction で何とかしたいな～、ということで知恵を絞る。っで、いろいろと見た感じだと、S2RequestProcessor の process(request,response) 処理で exportPropertiesToRequest のところまでを processAction で処理して、その状態(JSPのパスやリクエストのAttributeなど)を保持して、続きを render でやれば良さそうな気がしてきた。まだ細かい問題があるけど、そんな感じで修正したら、動くと思う。まぁ、これするのに processActionでサーブレットにディスパッチができないから、ポートレットの中でサーブレットを初期化してインスタンスを保持して、サーブレットフィルタの実行環境を書いたりと・・・。これらが一段楽したらコミットしよっと。結構、勉強になった。
5W1H
英語でやりとりしているときに 5W1H って使いたかったのだけど、これって英語で通じるのだろうか、とふと思い調べてみる。英語の Wikipedia とかみると、5W1H は Five Ws にリダイレクトされる。ってことは、Five Ws とか使った方が良いということだろうか。たぶん、通じなくはないのだろうけど、微妙感もありそうな気が。そんで、日本語の Wikipedia みてたら、
ただし「5W1H」という用語は日本独自のものであり、欧米ではふつう使われない。
って、書いてある・・・。ということは、微妙というか、通じない可能性が高いのね。
SAStruts for Portlet
やっと一段落。sa-struts-tutorial でいろいろと動作確認しているけど、基本的な部分は動いている気がする(トークンチェック以降は動かないものもあるけど)。ファイルアップロードについては、あとで対応しようかと。今回対応した内容だけど、JSR 168 の範囲内でできるようにがんばった。処理は基本的に render でしている。processAction だと、サーブレットにディスパッチできないので、何かのアクション時の処理は processAction で一時的にセッションに保存して、render でそれを取り出して、処理している。まぁ、ちょっと問題があって、render だと、リダイレクトができないので、仕方がないから javascript で出力後にリダイレクトしている(JSR 168 内でやろうとすると、これは仕方がない気もする。これはカスタマイズしやすいようにした方がいいかもな・・・)。
そんな感じで、調査から始めて１週間くらいかかりそうだなっと思っていたら、予定通りみたいな感じ(早く終わらしたかったのだけど)。本当は、Struts ブリッジがきれいに動くんだったら、そこをスクラッチしなくて済んで早く終わったはずだったのだけどな。というわけで、SAStruts も Seasar Conference のプレゼン資料に入れる方向ですすめよっと。