Differences between revisions 2 and 3
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
|
Wicketでこの機能を利用するには、基本的には[[guice/Servlet|サーブレット]]に記述した通りのことを行えばよい。 ただし、これをやっても[[guice/Wicket/Injection|インジェクション]]で取り上げた問題が解決するわけではない。 |
Wicketでこの機能を利用するには、基本的には「[[guice/Servlet|サーブレット]]」に記述した通りのことを行えばよい。 ただし、これをやっても「[[guice/Wicket/Injection|インジェクションの方法]]」で取り上げた問題が解決するわけではない。 |
GuiceFilterの利用
サーブレットフィルタとしてGuiceFilterを用いると、@SessionScopedや@RequestScopedのアノテーションが有効になる。 それらのスコープの制御は、Guiceがサーブレットからのリクエストをフックして行うからである。
Wicketでこの機能を利用するには、基本的には「サーブレット」に記述した通りのことを行えばよい。 ただし、これをやっても「インジェクションの方法」で取り上げた問題が解決するわけではない。 相変わらず以下の問題があるのでまとめておく。
- コンストラクタ注入されるオブジェクト以外はコンストラクタ中で使用することはできないが、一般にWicketのページクラスにはそのような特別なパラメータを指定できる余地がない。
- フィールド注入したとしても、Wicketのページは直列化されるため、それらのオブジェクトはSerizlizableでなければならず、大きいと直列化領域を圧迫する。なおかつ、直列化復帰後に（DB接続等の）機能を復旧できなければならない。
したがって、少なくともWicketのページ及びその中のコンポーネント等では、DIではなくサービスロケータを使用するのがベストであると結論づけた。
その上で、@SessionScoped/@RequestScopedの恩恵にあずかることはできる。 サービスロケータからこれらのオブジェクトを取得すると、それぞれセッションで一意なオブジェクト、リクエストで一意なオブジェクトを取得することができるのである。