On Fri, May 29, 2009 at 5:30 PM, Gavin King
<gavin.king@gmail.com> wrote:
OK, Dan, I'll have to respect your judgment on this because I'm not up
to date on how this stuff works in JSF2.
So I'm happy to make changes with respect to JSF conversation
propagation rules if it doesn't disrupt/delay the RI team (Pete,
WDYT?) and if there are no objections from the EG (anyone?).
But it seems that you're asking for two changes here:
(1) that the conversation is restored at the beginning of RESTORE_VIEW
This is my primary request. As of JSF 2, there is a lot of activity in the Restore View phase. It's highly likely that without an active conversation at that point, developers will find themselves in trouble. We should treat the restore view phase equally with the other phases. Thus, the conversation should be started before this phase is entered.
That, of course, rules out the possibility of storing the conversation token in the UIViewRoot, but I am strongly discouraging that approach looking ahead.
(2) that you want some kind of conversation propagation to other servlets
I have received a lot of inquires about whether the conversation is going to be avaiable in other servlets. I don't really see any reason why it can't be based on a filter...that would give you control over which requests participate in conversations right out of the box. And it would furthur clarify it's relationship with the request scope, in that they at the shortest map 1-to-1, with the conversation obviously being able to span multiple requests. But you also can have servlets don't participate in conversations.
Currently we don't even have a built-in conversation context in
servlets and we would need some kind of additional rules surrounding
conversation propagation between servlets. I think what you are
suggesting is that the conversation is propagated whenever there is a
request parameter named "cid" containing the conversation id, and that
it is the user's responsibility to pass it along through the view.
That doesn't sound unreasonable to me at this moment, and is probably
not very difficult to specify.
I would say it's more that if the developer/framework wants to use conversations in a given request, it would be allowed. Defining the boundaries as a servlet filter makes the most sense to me. And while it may not be specified, I think it would be understood that you have to propagate the conversation token using a mechanism which is portable enough to use in a filter (meaning not stored using a mechanism specific to JSF). Of course, the most portable and natural choice is the query string or path info.
-Dan