[webbeans-dev] conversation context lifecycle

[Dan Allen]

On Sun, May 31, 2009 at 8:23 AM, Clint Popetz <cpopetz at gmail.com> wrote:

>
>
> 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.)
>

Ah. Got it.


>
>
>
>> 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.
>

I'd support it, but it's not really my call to make.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090531/282d971e/attachment.html