or how bout conversation support for Wicket or Tapestry or GWT or Flex?
Section 5.3.2 of the reference manual seems to indicate that you can manually propagate the conversation with a non-faces request by including the unique identifier of the conversation as a request parameter. It is nicer with JSF because this happens automatically.
But ConversationPropagationFilter seems to have a hard coded dependency with JSF... does that mean I need to have the .jars of JSF copied in to my project even if I am not going to use it ever?
There will probably be a SPI for common conversation propagation.
Shoudn't it be the other wat around: common stuff as part of weld and the particular for some other tech as an SPI extension?
Mmmm, acording to the docs:
The conversation context is active during any JSF request.
Guess that decides it, Conversations are (for now) only for JSF. Guess it is time for a feature request in JIRA ;-)
Most conversations are destroyed at the end of the request. If a conversation should hold state across multiple requests, it must be explicitly promoted to a long-running conversation.
Oh, so Seam nomenclature gets altered? now they are not
long-running conversations, but only:
conversations and long-running conversations. That is unexpected since the last time I discussed about that people seem to regard
After reading Chapter 20 Alternative view layers I found this:
20.1.2. Conversations with Wicket
Wicket can also take advantage of the conversation scope from CDI, provided by the Wicket extension module.
After reading the code in org.jboss.weld.wicket.WeldRequestCycle I see it uses javax.enterprise.context.Conversation
So now I am confused... Is the implementation of Conversations in Weld dependant on JSF or not? Do I need to have JSF .jars in my Wicket for conversations to work property?
In another thread Gavin told me that:
Now, perhaps we got the line sightly wrong first time around - people are already yelling at me for not supporting injection of FacesContext out-of-the-box - and if so, we can fix it by adding a couple more objects to the list in section 3.6 of the spec.
While it would have been great to have Weld proportionate everything Seam proportionates, I think, a very clear line should be painted to prevent bloating. I think Weld should get thinner, and its boundaries clearly defined: For example, I think a weld-jsf.jar should be created (the JSF equivalente of weld-wicket.jar) to cleanly and clearly separate the part of Weld that is JSF dependant (and the part that is not)
What do you think about that?
I was going through some of the wicket-weld source code (I love how netbeans with maven grabs all the source for me automatically!) and found that there is a mechanism in the WeldApplication code for passing along the conversation id (CID) on form submits. So I'm assuming this means conversations are supported in Wicket, but I haven't tried it so I can't be sure.
Paul Mooney wrote on Nov 18, 2009 18:25:
I was going through some of the wicket-weld source code (I love how netbeans with maven grabs all the source for me automatically!) and found that there is a mechanism in the WeldApplication code for passing along the conversation id (CID) on form submits.
So I'm assuming this means conversations are supported in Wicket, but I haven't tried it so I can't be sure.
The questions is: are they supported in Wicket even if no JSF .jar is available in the classpath? And if they are, and having Conversations without JSF is so easy in Weld... why the warning in ConversationPropagationFilter?
Well, I think it's mostly to tell it's not a generic web filter.
You can write your own conversation manager (have a look in weld-api, ConversationManager and the ServletConversationManager in core), cid is just a token passed around an a small associated wrapped object with some state)
Conversations are supported in Weld's Wicket extension when used with Weld as the CDI container. If you try to use it with OWB for example, conversations won't work. Until the spec has a conversation manager we can't do much about this :-(