[
https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763940#action_12763940
]
Martin Marinschek commented on ORCHESTRA-40:
--------------------------------------------
Hi Mario,
> 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?
regards,
Martin
> 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.
