-
1. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
nickarls May 31, 2010 1:54 AM (in response to ifischer)Woiking on it: https://jira.jboss.org/browse/WELD-439
Reza had a tutorial recently on TSS: http://www.theserverside.com/tip/Dependency-Injection-in-Java-EE-6-Conversations-Part-4
Sort of
Conversations are named subsections of the session. The name is the conversation id. You call conversation.begin to mark a conversation non-transient. Non-transient conversations have their id:s propagated automagically to the next request and can be resumed. Transient conversations are destroyed at the end of the request -
2. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
ifischer May 31, 2010 2:23 PM (in response to ifischer)Thanks for creating the issue! Especially an example in relation to f:ajax would be interesting. I currently also have some problems with Conversations+Ajax+Validation.
So if there are no other tutorials (the one from Reza is good, but there is no source code and no Ajax) i'll post my current issue with Weld&Conversations during the next days. Just hoped i could solve it myself by reading more examples. -
3. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
hirowla.ian.rowlands.three.com.au May 31, 2010 8:59 PM (in response to ifischer)Don't know any other tutorials, but I can offer some of my own observations. Most of these are from having breakpoints in my code.
How f:ajax works in relation to backing beans depends on when it is invoked. One observation - every time you do an ajax call or conversation/validation call, a new backing bean is instantiated. At least UNTIL you move to a URL which includes the conversation Id as part of it. After that, you get the same bean (as expected). It's not intuitive but that's what happens and hence you need to code for it. Maybe it depends when you start your conversations. I was trying to only start conversation when I needed one, rather than starting one whether I needed to or not.
The way I think of them is session beans that you manually control - you need to say when you want to start saving them, and stop saving them. And remember to include the IDs in the URLs.
-
4. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
ifischer Jun 2, 2010 10:58 AM (in response to ifischer)> every time you do an ajax call or conversation/validation call, a new backing bean is
> instantiated. At least UNTIL you move to a URL which includes the conversation Id as part > of it. After that, you get the same bean (as expected)
Thanks for your comment! This is exactly my current problem, as i didn't move to a new url with the convId. I think that beside an example in the Weld-package, this should be mentioned in the Weld reference. -
5. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
ssamayoagt Jun 2, 2010 3:39 PM (in response to ifischer) -
6. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
infinity2heaven Feb 12, 2011 9:39 PM (in response to ifischer)I'm looking fwd for a Weld/Conversation/faces-config navigation working tutorial as well. Reza's example is too simple and the seam-javaee-booking in Seam3-beta1 is broken as the conversation use case doesn't work. Is this one of such features that gets crammed into the spec but isn't implemented right?
I remember Seam 2 conversation worked like charm.
-
7. Re: Need a good Weld Conversation (@ConversationScoped) tutorial
tony.herstell1 Jul 5, 2013 3:36 PM (in response to infinity2heaven)Priya M
> I remember Seam 2 conversation worked like charm.
I so agree...
Use Session scope to collect up the parts that you "might" want to work on, then use conversation scope to work on them...
Keep session stuff updated, using events, and you have reduced your DB access to nothing.
Well explained in the Seam 2 docu-tutorial..
Or Plan B...
Fetch everything again and again and again in Request Scope and limit your scalability massively and also run slowly...
Seam 2 really worked well; shame JEE 6/7 seems to have messed it up.