[
https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763854#action_12763854
]
Mario Ivankovits commented on ORCHESTRA-40:
-------------------------------------------
I think we all agree, having a decent handling for this thing is a long missing
feature here in JSF land.
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.
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.
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?
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.
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.
I am also constantly thinking about moving the conversationContext paramter
into the UIViewRoot - but this is another story.
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.
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?
Ciao,
Mario
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments:
> ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch,
> ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch,
> ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction
> processor.
> The transaction token is to be used for enforcing a single request for a
> particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
