この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
最新、Seasar2 ＋ Teedaのプロジェクトを作成しているので、
Teedaのsessionscopeについてメモします。
Teedaには、スコープにはいくつかありまして、
そのうち、サブアプリケーションスコープ（@SubapplicationScope）がドキュメントの書いた通り、
同じ サブアプリケーション のページを表示している間維持されるスコープです。
サブアプリケーションスコープは， 初期表示 や リダイレクト表示 で 他の サブアプリケーション から遷移した際に開始されます。
初期表示 や リダイレクト表示 で他のサブアプリケーションのページが要求されると破棄されて， 新しいサブアプリケーションスコープが開始されます．
サブアプリケーションの入力画面が非常に多い時、とても便利なものです。
ただし、
——-
初期表示 や リダイレクト表示 で他のサブアプリケーションのページが要求されると破棄されて， 新しいサブアプリケーションスコープが開始されます．
——-
ということで、一連の操作の途中に万が一、同じブラウザで、別サブアプリケーションへアクセスすると、
一連の操作は続けられなくなってしまう可能性が十分ありますので、ご注意ください。
例えば、
Aというサブアプリケーションには
入力画面1～5、確認画面、完了画面からなります。
入力画面が多いので、全ての項目をhiddenで渡すと、しんどいので、
———–
@SubapplicationScope
public TestDto test;
———–
を定義して、入力画面の入力項目を格納しました。
偶然、入力画面2が開いている中、別のサブアプリケーションBの画面を見たくて、
同じブラウザで、Bの画面へアクセスしました。
そうすると、また、Aの入力画面2に戻って、次へボタンを押すと、testがNULLになって、
NullPoint例外が投げられました。
なぜでしょうかと考えると、@SubapplicationScopeの仕様にぴったりでした。
ある機能操作中、別機能の画面を見るのは少ないケースですが、ないわけではない。
@SubapplicationScopeを使用するとき、ご注意ください。
↑のケースにはどうしても操作を続けたいという希望があるので、
セッションを使うようにしました。
TestDtoを「@Component(instance = InstanceType.SESSION)」で定義して、
Page側で、セッションとして使うとき、
———-
@Binding(bindingType = BindingType.MUST)
protected TestDto testDto;
———-
のように定義すれば、testDtoはセッション級のものとして、使えます。
（※自動バインディングのルールとしてクラス名がTestDtoである場合、変数名はtestDtoにしないと、自動バインディングしてくれないのでご注意）
セッションから、removeは
最後の完了ページが表示されるとき、
@RemoveSession(name={“testDto”})
public Class prerender() {
return null;
}
すれば良いです。
