JSF CDI : Conversation scope bean[s] best practice

11
votes

I'm currently learning about JSF 2.0 and im so glad for the existence of this conversation scope feature, which is very helpful in opening a new tab or a new window on the same page and having separate resources, not overriding one another.

But im curious on how to implement this in a good way, about when to start the conversation and when to close it.

In my case, i have each CDI bean for each JSF page. And let's say that i have a menu, and when it's clicked, this will lead to page A, and from A, could lead to B, B could lead to C, C could lead to D, all these 4 pages are connected in one chain.

Accessing A's bean properties from B or C or D beans is possible, accessing B's properties is also possible from C or D beans and so forth.

Now im quite confused about :

  • whether all these A B C D should be in conversation scope or not, or perhaps just A ? Because i think sometimes from another page that is outside the ABCD chain, like a page F, it could navigate to page B, although i dont know how to supply the data to the bean B yet.
  • whether all these A B C D should be combined into one bean
  • where and when to start the conversation, im thinking about the constructor, but i dont think it's a good idea, because i prefer starting the conversation when first accessing the page, not the bean
  • where and when to stop the conversation, so that there wont be unused resources hanging around

Please share your thoughts on this.

1
javajsfjsf-2
CDI is not part of standard JSF. CDI stands for Contexts and Dependency Injection (JSR-299) which covers the annotations of javax.enterprise package. Conversation Scope is also not part of standard JSF. It was an JBoss Seam invention during JSF 1.2 ages and has been adopted by JSF 2.0 specification as View Scope, togglable by @ViewScoped annotation. Now, what are you actually talking about? - BalusC
Hello BalusC, thanks for the clarification. I used the term CDI just to make clear what i'm using, but maybe that information is unrelated to my question, my apology :) As far as i know, the @ViewScoped is for a single page getting redisplayed and the properties will be persisted. But what i wanted to achieve from conversation scope is that i can open the same page on several tabs, with each tab as if having it's own session scope. So submitting the value 'albert' on a myBean.name on a tab wont override the myBean.name on other tabs. But im confused on where to start and end the conversation. - Albert Gan
And this gets more confusing for me if there are 4 pages, for example, page A is a browse page, where user can search, page B is the detail page, where user can modify details, page C is where user can modify sub detail, and so forth. If i wanted to be able to open page A in several tabs without one affecting another, i have to use conversation scope on A's bean. But i suppose it's gonna be conversation scope too for B C and D ? Also about where and when should i begin / end the conversation. I mean, user can open new tabs, and close the tabs. How can i detect this and close the conversation ? - Albert Gan
Albert, when replying to comments in posts which are not the commenter's own, use @nickname like @BalusC to get them automatically notified about the comment-reply. See also meta.stackexchange.com/questions/43019/… - BalusC

1 Answers

11
votes

JSF 2 provides Request, View, Session, and Application scopes. CDI introduces the Conversation scope, but more importantly, it introduces a standard by which new scopes can be added to the platform.

The Scope you are describing is probably better suited by a custom scope like a window scope. Two projects implementing this scope are:

  1. Apache MyFaces CODI
  2. IceFaces has a JSF (non-CDI) Window scope implementation.

Nevertheless, I would encourage you to rethink your bean structure. I've become quite fond of the View scope myself, coupled with the JSF 2 view parameters to propagate information from one page to another (and from one View scope instance to another).

MyFaces "View Access" scope seems like another neat approach, where a bean stays in scope so long as the pages you navigate through maintain a reference to that scope.