On Sat, May 30, 2009 at 5:26 PM, Clint Popetz
<cpopetz@gmail.com> wrote:
The wicket webbeans conversation mechanism stores the conversation id in a page map that is only accessible once the wicket filter has run and determined which page is being used. So this mechanism wouldn't work for Wicket. However since there is no default cid=NNN parameter being generated by anyone for wicket, and the conversation mechanism in the container just defaults to a transient conversation without one, the wicket conversation hooks that runs from the WicketFilter can (I presume) still obtain the @Current Conversation and call begin(id) once it has found the correct id in the page map.
So I think this mechanism won't keep frameworks like wicket from operating conversationally.
The problem you describe with Wicket is exactly what I want to
avoid with JSF. In JSF, it's a chicken egg problem to try to restore
the view to determine what type of conversation you have active. So I
definitely support having the conversation start as early as possible,
before application code starts firing. I think it is mistake to bury conversation token information in a page object. It needs to be there before the framework gets going. So I support doing this before filters fire.
You can always decide to end the conversation or recreate it once you determine that, for whatever reason, you don't want that conversation (I'm not able to come up with a scenario right now).
Another approach is to have the framework (JSF, Wicket, etc) raise the event to instruct the manager how to construct the conversation. In the case of Wicket, you could do that somewhere mid-way in the filter.
-Dan