どの@ConversationScoped
CDI Bean にも、次のフィールドが必要です。
@Inject
private Conversation conversation;
会話を開始するときはいつでも、Bean が状態にあるかどうかを確認する必要がありますtransient
。それ以外の場合は、IllegalStateException
スローされます。次のようになります。
public void beginConversation() {
if (conversation.isTransient()) conversation.begin();
}
これにより、Bean はlong-running
状態になります。したがって、ユーザーがページから離れて後で戻ってきた場合、会話がタイムアウトしたかどうかをいつでも確認して、離れたページに移動させることができます。
その上、しばらくの間、@ViewScoped
ManagedBeanをCDI Beanと一緒に使用しています。CDI BeanをMangedBean@Inject
に注入するために引き続き使用できます。私はあなたが逆にできるとは思わない。とにかく、これが後で悪いことが起こるかどうかはわかりません。しかし、これまでのところ、問題に遭遇したことはありません。本当に を使いたい場合は 、試してみるとよいと思います:P.@ViewScoped
アップデート:
会話スコープは、典型的な AJAX の状況でビュー スコープに代わる価値のあるものですか?
@ConversationScoped
を完全に置き換えることはできないと思います@ViewScoped
。
ビュー スコープと同様に、セッションごとに複数のインスタンスを許可しますか?
いいえ、セッションごとに複数のインスタンスを持つことはできません。前述したように、古い会話がまだlong-running
状態にある間に新しい会話を開始すると、IllegalStateException
.
落とし穴は何ですか?
@ViewScoped
overの主な利点の 1 つは@RequestScoped
、ユーザーが同じビューにフォームを送信するたびにデータを再開始する必要がないことです。ただし、 では@ConversationScoped
、この利点が過剰に使用されています。この問題は を使用する場合ほど深刻ではありませんが、 Bean が存続@SessionScoped
する限り、開始されたデータを保持する必要があります。@ConversationScoped
会話が長くなればなるほど、より多くのデータを保持する必要があります。