On Sun, May 31, 2009 at 1:52 AM, Dan Allen <dan.j.allen@gmail.com> wrote:

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.

I think that depends on your framework.  Wicket already _has_ a notion of conversations, and it uses per-page-maps for storage of the models and pages that make up this conversation.  It's a very natural extension to use this for storing webbeans conversation ids.  What's more, wicket abstracts away the url/request-parameter scheme, so that apps do not build urls by hand, but instead use url encoding strategies that are picked per-app and sometimes per-section-of-app.   In the first rev of the seam/wicket integration we used request parameters and redirect filters to attempt make the seam 'cid' notion onto wicket, and it was a mess.  It now uses the page map and it is very intuitive.

There is no chicken and egg problem for Wicket. There is a very distinct boundary between where wicket framework code is operating and where pages written by wicket developers start firing, and this gives a very clear place to start conversations: after the framework has determined what page has been hit (or in wicket lingo, what "request target" since it could be something besides a page, like a resource.)

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.

This is the approach I prefer.  The notion of when and how to start a conversation depends on the framework, and the framework should trigger it, IMHO.  I don't care whether it's an event or an SPI interface method.