> I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land.
yes, it really is.
> I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else.
well, I believe it is also a problem with normal session scope, but no one should be using the session scope anyways
> The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the
> conversationContext I can not see anything which can not be solved using normal JSF phase listeners.
> And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to
> decide on which level the tokens are kept.
> If you do not use Orchestra you simply can the manager bean into the session then.
Ok, sure, this might as well work without orchestra - but you definitely need a window/tab concept. And isn't that something orchestra also tries to solve?
> I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that -
> compared to seam and webflow - people await such functionality from Orchestra too.
> If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible?
Why jsfext? Does the solution have anything to do with JSF per se? The default implementation of the listener might have a JSF implication, but apart from that, no. Again, I think the whole thing is bound to windows and tabs, and therefore needs to reside in Orchestra or on top of Orchestra as a module of Orchestra - where exactly is not so much of an issue to me.
> As for the technical aspect of this patch, I have some notes:
> 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection
>needs to be added, at least to detect JSF 2.0 alike ajax requests.
Hmm, I am not sure. Shouldn't we just make sure that the parameter gets updated like in the normal request case?
> 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better.
> If you have to deal with ajax requests you are able to update this value then with the new token.
ok, yes - then this would be somewhat automatic.
> I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story.
sounds good to me.
> 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People
> than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get
> some feedback.
yes, and that might be JSF specific - jump to the rendering phase, and add a faces-message. Exactly.
> 4) I'd like to have a way to "ignore" some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change),
> the browser stay on the page, but the token has been "used" then.
> The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like
> TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again.
> Also trinidad has at least two components which open a window and just report the value back to the main window.
> Probably we also need a way to ignore requests based on an URL pattern to deal with that?
Yes, there needs to be a way to cover this usecase. Isn't the target attribute the determining factor?