adfemg
  1. adfemg
  2. ADFEMG-53

Enable User Customizations across Sessions using MDS can break ADF Application

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Works as designed
    • Labels:
      None

      Description

      Environment

      • JDeveloper/ADF version : 11.1.2.0 - 11.1.2.2
      • WebLogic Server version : n.a.
      • impact level : HIGH
      • why : break complete user interface interaction

      Summary

      Enable User Customizations across Sessions using MDS.

      See blog post for detailed description and screenshots.

      Steps to reproduce

      • Create a application with af:forEach and af:accordion for dynamic UI
      • Enable User Customizations across Sessions using MDS
      • (Optional) Deactivate all persistent options for showDetailItem
      • Run ADF App
      • Try to open the accordion several times

      Occured result/behaviour

      • after some clicks the ui freeze and must be refreshed

      Expected result/behaviour

      • Enable User Customizations across Sessions using MDS should not have negative impact on the application.

      Testcase

      Further information

        Activity

        Hide
        duncanmills added a comment -

        There is no need to use af:forEach in facelets because c:forEach works correctly. Note that af:forEach was only created in the first place because of shortcomings in the JSTL version.
        However, af:forEach does still function and I think that it actually just uses c:forEach internally anyway.
        The actual problem here is discussed in the JavaServer Faces issues repository (it's a JSF issue not an ADF issue): http://java.net/jira/browse/JAVASERVERFACES-1527, as you see it's the same for both af: and c:forEach

        Show
        duncanmills added a comment - There is no need to use af:forEach in facelets because c:forEach works correctly. Note that af:forEach was only created in the first place because of shortcomings in the JSTL version. However, af:forEach does still function and I think that it actually just uses c:forEach internally anyway. The actual problem here is discussed in the JavaServer Faces issues repository (it's a JSF issue not an ADF issue): http://java.net/jira/browse/JAVASERVERFACES-1527 , as you see it's the same for both af: and c:forEach
        Hide
        Jan Vervecken added a comment -

        Thank you for the insights Duncan.

        As you write in your blog post [1]

        • (st1) "... JSF under JSP implements some hacks ... to transparently fix this problem for you ..."
        • (st2) "... when running with Facelets ... JSF does not mess around in the background for you ..."
        • (q1) Are both (st1) and (st2) intended behaviour?

        It seems strange that for a given af:forEach the run-time behaviour can be so different.
        Or is this covered by the af:forEach tag documentation [2] saying
        "Note: this tag is not supported in Facelets, because c:forEach is fully functional in Facelets."

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the insights Duncan. As you write in your blog post [1] (st1) "... JSF under JSP implements some hacks ... to transparently fix this problem for you ..." (st2) "... when running with Facelets ... JSF does not mess around in the background for you ..." (q1) Are both (st1) and (st2) intended behaviour? It seems strange that for a given af:forEach the run-time behaviour can be so different. Or is this covered by the af:forEach tag documentation [2] saying "Note: this tag is not supported in Facelets, because c:forEach is fully functional in Facelets." [1] https://blogs.oracle.com/groundside/entry/foreach_and_facelets_a_bugfarm [2] http://docs.oracle.com/cd/E26098_01/apirefs.1112/e17491/tagdoc/af_forEach.html regards Jan Vervecken
        Hide
        duncanmills added a comment -

        This is down to the behaviour of unique ID generation (or not) within the scope of forEach loops.
        See: https://blogs.oracle.com/groundside/entry/foreach_and_facelets_a_bugfarm

        Show
        duncanmills added a comment - This is down to the behaviour of unique ID generation (or not) within the scope of forEach loops. See: https://blogs.oracle.com/groundside/entry/foreach_and_facelets_a_bugfarm
        Hide
        Ulrich Gerkmann-Bartels added a comment -

        Great - i try (2) and i can confirm it works

        Show
        Ulrich Gerkmann-Bartels added a comment - Great - i try (2) and i can confirm it works
        Hide
        duncanmills added a comment -

        OK I think I've got to the bottom of this and it's simple to fix. The root of the issue here is a difference in behaviour between JSP and Facelets as a page technology.
        The JSP engine has some hacks in it to prevent duplicate IDs in the case of a forEach loop. Facelets does not so you have to be careful.
        The solution in your example is to either:
        1) Remove the ID attribute from your showDetailItems and let JSF generate them.
        or
        2) Amend the ID attribute to something like: <af:showDetailItem id="sdi3_#

        {accord.index}

        " ... to ensure a unique id

        This will ensure that every instance of the showDetail has a unique ID.

        Give that a go...

        Show
        duncanmills added a comment - OK I think I've got to the bottom of this and it's simple to fix. The root of the issue here is a difference in behaviour between JSP and Facelets as a page technology. The JSP engine has some hacks in it to prevent duplicate IDs in the case of a forEach loop. Facelets does not so you have to be careful. The solution in your example is to either: 1) Remove the ID attribute from your showDetailItems and let JSF generate them. or 2) Amend the ID attribute to something like: <af:showDetailItem id="sdi3_# {accord.index} " ... to ensure a unique id This will ensure that every instance of the showDetail has a unique ID. Give that a go...
        Hide
        duncanmills added a comment -

        Right I've done some digging in this.
        We started to support the persistence of items within iterators and forEach in 11.1.2+ So that probably has a bearing on this.
        Running in Chrome I can observe the following:
        1) If I run without 'Enable User Customizations' when it works OK
        2) If I run with 'Enable User Customizations' but only for the duration of the session it works although the response on the disclose seems a little sluggish
        3) If I run with 'Enable User Customizations' Across Sessions then the first disclose does not quite fail - there is a slight UI change but the detail is not shown. Subsequent disclose attempts generate a JavaScript error "Unexpected panelAccordion showDetailItem disclosure state for queueing client events" If you then refresh the page then it starts to function.

        Show
        duncanmills added a comment - Right I've done some digging in this. We started to support the persistence of items within iterators and forEach in 11.1.2+ So that probably has a bearing on this. Running in Chrome I can observe the following: 1) If I run without 'Enable User Customizations' when it works OK 2) If I run with 'Enable User Customizations' but only for the duration of the session it works although the response on the disclose seems a little sluggish 3) If I run with 'Enable User Customizations' Across Sessions then the first disclose does not quite fail - there is a slight UI change but the detail is not shown. Subsequent disclose attempts generate a JavaScript error "Unexpected panelAccordion showDetailItem disclosure state for queueing client events" If you then refresh the page then it starts to function.
        Hide
        duncanmills added a comment -

        My suspicion here would be specifically aimed at the use of af:forEach within the accordion - checking this out.

        Show
        duncanmills added a comment - My suspicion here would be specifically aimed at the use of af:forEach within the accordion - checking this out.

          People

          • Assignee:
            duncanmills
            Reporter:
            Ulrich Gerkmann-Bartels
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: