Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7DR#3
    • Fix Version/s: 1.8.2-EE-GA_P02
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      ICEfaces

      Description


      Submitting a form twice often causes problems with the application state machine (such as a double billed credit card). It would be desirable for ICEfaces to disable submission until acknowledgement from the server was received. A general mechanism in the bridge could be applied to this (discard all events until a server response), as well, a simpler solution would be to add a mode to the submit button so that the button would be immediately disabled when pressed, then would become enabled again when a server response was received.

        Issue Links

          Activity

          Hide
          Ken Fyten added a comment -

          This issue is resolved with the fixes for blockUIOnSubmit.

          Show
          Ken Fyten added a comment - This issue is resolved with the fixes for blockUIOnSubmit.
          Hide
          Ken Fyten added a comment -

          This issue is partially addressed by the "blockUIOnSubmit" feature added in 1.8. However, that feature has a nasty side-effect of also blocking button action events that trigger a partial-submit on a previously focussed component (see ICE-4308).

          We've also had some success with a DoubleSubmitPhaseListener implementation that ignores subsequent submits while the first is processing, but it to suffers from the use-case described above.

          We need to review this again, it may be possible to implement a fix that keeps track of the "previous event" and allows onblur events to not block subsequent events – this may actually be a general solution.

          Show
          Ken Fyten added a comment - This issue is partially addressed by the "blockUIOnSubmit" feature added in 1.8. However, that feature has a nasty side-effect of also blocking button action events that trigger a partial-submit on a previously focussed component (see ICE-4308 ). We've also had some success with a DoubleSubmitPhaseListener implementation that ignores subsequent submits while the first is processing, but it to suffers from the use-case described above. We need to review this again, it may be possible to implement a fix that keeps track of the "previous event" and allows onblur events to not block subsequent events – this may actually be a general solution.
          Hide
          Faruk Onder added a comment - - edited

          this problem also occurs after valuechange events. for example , in selectonemenu. after changing it is value, if submit a button before responce comes from valuechange, all the states gone down. values set wrong components. fresh datas gone .

          it is a very big problem for icefaces.

          may be this is a solution:

          if a range that holds areas which disables first by clicking or after value changes in client side , then it is not important when the responce is come
          and responce come, re enable this areas

          like a4j , reRender attribute

          but the disable operation MUST fired in client side ,

          we are making this solution manually,

          Show
          Faruk Onder added a comment - - edited this problem also occurs after valuechange events. for example , in selectonemenu. after changing it is value, if submit a button before responce comes from valuechange, all the states gone down. values set wrong components. fresh datas gone . it is a very big problem for icefaces. may be this is a solution: if a range that holds areas which disables first by clicking or after value changes in client side , then it is not important when the responce is come and responce come, re enable this areas like a4j , reRender attribute but the disable operation MUST fired in client side , we are making this solution manually,
          Hide
          Alan Biggs added a comment -

          To me, the real issue here is that ICEfaces, in asynchronous operation, can create serious issues for application usability and performance. This is because it does not offer a clear way to suppress (i.e. block) asyncronous operation.
          I believe that an application developer should have the ability within the framework to specify whether an operation is asynchoronous or synchronous by nature.
          A default implementation of synchronous operation should be offered by the framework, which can be overridden by the developer if required.

          Case study: A form lists all records in a table and also shows a detailed view of a record when an item is selected in the list.
          In normal operation, a user selects an item from the list and expects to see the details of that item in the form. Ideally this happens instantaneously.
          However, latency is significant on a particular system and it takes five seconds to load the details into the form after the event is sent to the server.
          In asynchronous operation the user may continue to click on other items in the list. The requests are all queued, and the results come back one after the other replacing the values in the form in succession.
          This is a usability issue - the behaviour is not expected by the user and is likely to frustrate or annoy. It is also a serious performance issue, especially in situations where a system which is already suffering from slow performance is bogged down by several more unnecessary requests due to artbitrary user actions.

          In this situation it seems clear that the correct mode of operation is synchronous.
          A preferable behaviour is to somehow block further user action until the results are returned, or a timeout occurs.

          I suggest that in this mode of operation a busy indicator should be shown in the UI and further input (or at least submits) should be denied until the operation is complete. A suggestion of how to achieve this is to include a transparent blocking pane (div) which is enabled during a synchronous operation to prevent any events being sent through to the underlying components. The busy indicator helps the user to intuitively understand that the system is not in the mode of accepting input at present.

          Show
          Alan Biggs added a comment - To me, the real issue here is that ICEfaces, in asynchronous operation, can create serious issues for application usability and performance. This is because it does not offer a clear way to suppress (i.e. block) asyncronous operation. I believe that an application developer should have the ability within the framework to specify whether an operation is asynchoronous or synchronous by nature. A default implementation of synchronous operation should be offered by the framework, which can be overridden by the developer if required. Case study: A form lists all records in a table and also shows a detailed view of a record when an item is selected in the list. In normal operation, a user selects an item from the list and expects to see the details of that item in the form. Ideally this happens instantaneously. However, latency is significant on a particular system and it takes five seconds to load the details into the form after the event is sent to the server. In asynchronous operation the user may continue to click on other items in the list. The requests are all queued, and the results come back one after the other replacing the values in the form in succession. This is a usability issue - the behaviour is not expected by the user and is likely to frustrate or annoy. It is also a serious performance issue, especially in situations where a system which is already suffering from slow performance is bogged down by several more unnecessary requests due to artbitrary user actions. In this situation it seems clear that the correct mode of operation is synchronous. A preferable behaviour is to somehow block further user action until the results are returned, or a timeout occurs. I suggest that in this mode of operation a busy indicator should be shown in the UI and further input (or at least submits) should be denied until the operation is complete. A suggestion of how to achieve this is to include a transparent blocking pane (div) which is enabled during a synchronous operation to prevent any events being sent through to the underlying components. The busy indicator helps the user to intuitively understand that the system is not in the mode of accepting input at present.
          Hide
          Nicklas Karlsson added a comment -

          And, of course, in relation to the disableGroup attribute would be the ability to right-click on the connection status to get a popup list of groups currently busy and the ability to cancel selected jobs

          So if I have four buttons: a, b belonging to job group "foo" and c, d belonging to job group "bar", I click on button a and buttons a and b goes disabled. Then I click on button d and buttons c,d goes disabled, then I right click on the connection status and choose "foo" and buttons a,b become available again.

          Show
          Nicklas Karlsson added a comment - And, of course, in relation to the disableGroup attribute would be the ability to right-click on the connection status to get a popup list of groups currently busy and the ability to cancel selected jobs So if I have four buttons: a, b belonging to job group "foo" and c, d belonging to job group "bar", I click on button a and buttons a and b goes disabled. Then I click on button d and buttons c,d goes disabled, then I right click on the connection status and choose "foo" and buttons a,b become available again.
          Hide
          Nicklas Karlsson added a comment -

          That would be a very welcome feature.

          One bonus feature would be the ability to set a "disabledGroup" or similar attribute that would disable every button in that group if one
          of them is processing a request.

          And if all this would be applicable to commandLinks also, all the better.

          Show
          Nicklas Karlsson added a comment - That would be a very welcome feature. One bonus feature would be the ability to set a "disabledGroup" or similar attribute that would disable every button in that group if one of them is processing a request. And if all this would be applicable to commandLinks also, all the better.

            People

            • Assignee:
              Ted Goddard
              Reporter:
              Ted Goddard
            • Votes:
              41 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: