Re: [webbeans-dev] conversation context lifecycle
On Sun, May 31, 2009 at 1:52 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Sat, May 30, 2009 at 5:26 PM, Clint Popetz
<cpopetz(a)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.
-Clint
Attachments:
- attachment.html (text/html — 3.9 KB)