[webbeans-dev] conversation context lifecycle

[Clint Popetz]

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

> On Sat, May 30, 2009 at 5:26 PM, Clint Popetz <cpopetz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090531/cc6fec01/attachment.html