On Sun, May 31, 2009 at 8:23 AM, Clint Popetz <cpopetz(a)gmail.com> wrote:
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.)
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.
Senior Software Engineer, Red Hat | Author of Seam in Action
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.