ICEfaces
  1. ICEfaces
  2. ICE-11560

WebSphere AS 8.5, the whole view is reset at requests with render="@all"

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: EE-4.3.0.GA_P05, EE-3.3.0.GA_P11
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      WAS 8.5.5.18
    • Support Case References:
      Volkswagen
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      The workaround consists in avoiding the use of render="@all" in ajax requests and instead using render="@form", so that the whole view doesn't have to be updated, and therefore no dynamic updates for the whole view are sent to the browser. If a view has multiple forms that you wish to have updated in the same ajax request, then simply specify them in the 'render' attribute, e.g. render="@form form2 form3".
      Show
      The workaround consists in avoiding the use of render="@all" in ajax requests and instead using render="@form", so that the whole view doesn't have to be updated, and therefore no dynamic updates for the whole view are sent to the browser. If a view has multiple forms that you wish to have updated in the same ajax request, then simply specify them in the 'render' attribute, e.g. render="@form form2 form3".

      Description

      The problem is not so much that the whole view gets reset when a component uses render="@all" in its ajax tag. What happens is that on an ajax render-all request, the whole view is getting dynamically updated. This means that the whole markup is being replaced in-place in the browser. This means that the HTML nodes that already had some input from the user get replaced by identical nodes but without that input that the user had entered. So, it looks like the whole view is reset. However, if these components had the default ajax tag or at least the ajax tag with execute="@this" render="@none", that value persisted when this issue occurred, because the value had already been saved when the user entered it.

      The whole view is getting updated for an unknown reason. What we observed was that a couple of form elements that ICEfaces uses internally (single-submit and retrieve-update) are getting a new client ID at every ajax render-all request, and because these form elements are first-level children, this is triggering the whole view to be updated according to our DOMdiff rules. However, it seems to be a more general JSF issue, because we also tested with a pure, standard JSF test case, and we could see a similar behaviour. We didn't see these system form elements changing client IDs, because standard jSF doesn't use them, but we saw that the whole view was getting updated as well, at every ajax render-all request, and we also observed that all values in the view were reset, and no value could be saved, even for the very component that triggered that request.

        Activity

        Arturo Zambrano created issue -
        Arturo Zambrano made changes -
        Field Original Value New Value
        Fix Version/s EE-4.3.0.GA_P06 [ 14175 ]
        Fix Version/s EE-3.3.0.GA_P12 [ 14176 ]
        Arturo Zambrano made changes -
        Description The problem is not so much that the whole view gets reset when a component uses render="@all" in its ajax tag. What happens is that on an ajax render-all request, the whole view is getting dynamically updated. This means that the whole markup is being replaced in-place in the browser. This means that the HTML nodes that already had some input from the user get replaced by identical nodes but without that input that the user had entered. So, it looks like the whole view is reset. However, if these components had the default ajax tag or at least the ajax tag with execute="@this" render="@none", that value persisted when this issue occurred, because the value had already been saved when the user entered it.

        The whole view is getting updated for an unknown reason. What we observed was that a couple of form elements that ICEfaces uses internally are getting a new client ID at every ajax render-all request, and because these form elements are first-level children, this is triggering the whole view to be updated according to our DOMdiff rules. However, it seems to be a more general JSF issue, because we also tested with a pure, standard JSF test case, and we could see a similar behaviour. We didn't see these system form elements changing client IDs, because standard jSF doesn't use them, but we saw that the whole view was getting updated as well, at every ajax render-all request, and we also observed that all values in the view were reset, and no value could be saved, even for the very component that triggered that request.
        The problem is not so much that the whole view gets reset when a component uses render="@all" in its ajax tag. What happens is that on an ajax render-all request, the whole view is getting dynamically updated. This means that the whole markup is being replaced in-place in the browser. This means that the HTML nodes that already had some input from the user get replaced by identical nodes but without that input that the user had entered. So, it looks like the whole view is reset. However, if these components had the default ajax tag or at least the ajax tag with execute="@this" render="@none", that value persisted when this issue occurred, because the value had already been saved when the user entered it.

        The whole view is getting updated for an unknown reason. What we observed was that a couple of form elements that ICEfaces uses internally (single-submit and retrieve-update) are getting a new client ID at every ajax render-all request, and because these form elements are first-level children, this is triggering the whole view to be updated according to our DOMdiff rules. However, it seems to be a more general JSF issue, because we also tested with a pure, standard JSF test case, and we could see a similar behaviour. We didn't see these system form elements changing client IDs, because standard jSF doesn't use them, but we saw that the whole view was getting updated as well, at every ajax render-all request, and we also observed that all values in the view were reset, and no value could be saved, even for the very component that triggered that request.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arturo Zambrano
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: