MyFaces Orchestra
  1. MyFaces Orchestra
  2. ORCHESTRA-40

A transaction token component inspired by the struts transaction processor

    Details

    • Type: New Feature New Feature
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.3.1
    • Fix Version/s: None
    • Component/s: Conversation
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Bernd Bohmann added a comment -

        Hello Simon,

        can you review the patch. This is only draft now. May be better included in Conversation? What do you think?

        Thanks

        Bernd

        Show
        Bernd Bohmann added a comment - Hello Simon, can you review the patch. This is only draft now. May be better included in Conversation? What do you think? Thanks Bernd
        Hide
        Bernd Bohmann added a comment -

        Added a Cache Control RequestHandler. If enabled this RequestHandler add some Cache Control Response Header.
        Added a new Transaction Token patch.

        Show
        Bernd Bohmann added a comment - Added a Cache Control RequestHandler. If enabled this RequestHandler add some Cache Control Response Header. Added a new Transaction Token patch.
        Hide
        Simon Kitching added a comment -

        Could you describe some of the use-cases for this?

        For transaction-oriented websites, back-buttons or "double clicking" of a page can be nasty; it can cause operations to be done multiple times (eg buying multiple copies of something) when the user didn't want that. The standard way to detect back-button usage or "double clicks" on a web page is to have a counter component in the page, and a matching counter in the http session. Both get incremented on each request; if at the start of a request they don't match then we have one of the above problems.

        If I understand correctly, this patch adds a conversation-aware version of this, which stores the counter in "the current conversation" for the submitting page. But I'm not sure why this is useful. Why isn't a normal non-conversation-aware token implementation sufficient?

        Note that the Orchestra ViewController already has features to detect when a page tries to use a conversation that does not exist (eg because it has been invalidated at end of a transaction), and can redirect to the appropriate "entry" page for the conversation.

        Show
        Simon Kitching added a comment - Could you describe some of the use-cases for this? For transaction-oriented websites, back-buttons or "double clicking" of a page can be nasty; it can cause operations to be done multiple times (eg buying multiple copies of something) when the user didn't want that. The standard way to detect back-button usage or "double clicks" on a web page is to have a counter component in the page, and a matching counter in the http session. Both get incremented on each request; if at the start of a request they don't match then we have one of the above problems. If I understand correctly, this patch adds a conversation-aware version of this, which stores the counter in "the current conversation" for the submitting page. But I'm not sure why this is useful. Why isn't a normal non-conversation-aware token implementation sufficient? Note that the Orchestra ViewController already has features to detect when a page tries to use a conversation that does not exist (eg because it has been invalidated at end of a transaction), and can redirect to the appropriate "entry" page for the conversation.
        Hide
        Bernd Bohmann added a comment -

        Added a non Component based TransactionToken patch

        Show
        Bernd Bohmann added a comment - Added a non Component based TransactionToken patch
        Hide
        Bernd Bohmann added a comment -

        A session based counter would not work if you allow to open more than one page.

        Show
        Bernd Bohmann added a comment - A session based counter would not work if you allow to open more than one page.
        Hide
        Bernd Bohmann added a comment -

        added new patch
        ensure ConversationRequestParameterProvider() is registered
        avoid concurrent modification exception

        Show
        Bernd Bohmann added a comment - added new patch ensure ConversationRequestParameterProvider() is registered avoid concurrent modification exception
        Hide
        Bernd Bohmann added a comment -

        Added new patch with a transactionTokenListener ManagedBean
        Maybe this should be a spring bean?

        Show
        Bernd Bohmann added a comment - Added new patch with a transactionTokenListener ManagedBean Maybe this should be a spring bean?
        Hide
        Bernd Bohmann added a comment -

        renamed patch

        Show
        Bernd Bohmann added a comment - renamed patch
        Hide
        Bernd Bohmann added a comment -

        Maybe this can be included as a different artifact for orchestra?

        Show
        Bernd Bohmann added a comment - Maybe this can be included as a different artifact for orchestra?
        Hide
        Manfred Geiler added a comment -

        MANAGED_BEAN_NAME = "org.apache.myfaces.orchestra.TransactionToken"
        is suboptimal because dots are (officially) not allowed within a managed bean name.
        Only underscores, letters and digits are allowed according to jsf spec.

        Show
        Manfred Geiler added a comment - MANAGED_BEAN_NAME = "org.apache.myfaces.orchestra.TransactionToken" is suboptimal because dots are (officially) not allowed within a managed bean name. Only underscores, letters and digits are allowed according to jsf spec.
        Hide
        Manfred Geiler added a comment -

        The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener.
        (looks like a debugging remainder)

        Show
        Manfred Geiler added a comment - The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener. (looks like a debugging remainder)
        Hide
        Martin Marinschek added a comment -

        Ok, so there was a lot of action here, but not really a lot of discussion.

        Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc.

        As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases.

        Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session).

        If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it).

        regards,

        Martin

        Show
        Martin Marinschek added a comment - Ok, so there was a lot of action here, but not really a lot of discussion. Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc. As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases. Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session). If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it). regards, Martin
        Hide
        Mario Ivankovits added a comment -

        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

        Show
        Mario Ivankovits added a comment - 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
        Hide
        Martin Marinschek added a comment -

        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

        Show
        Martin Marinschek added a comment - 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
        Hide
        Bernd Bohmann added a comment -

        Added new patch with initial ajax support.

        Show
        Bernd Bohmann added a comment - Added new patch with initial ajax support.

          People

          • Assignee:
            Simon Kitching
            Reporter:
            Bernd Bohmann
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development