adfemg
  1. adfemg
  2. ADFEMG-65

Automatic PPR stops working in jdev 11.1.2.x when using an af:exportCollectionActionListener

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Labels:
      None
    • Environment:

      JDev 11.1.2.3.0 on Win7 64bit

      Description

      Consider the following use case (based on the HR schema):
      On onr page a master form is shown with details as a table on the same page. The details should be expoerted to Excel using an af:exportCollectionActionListener.

      Page layout: Departments used as form on a page with navigation buttons, below the department form are the Employees of the department as table in a af:panelCollection with an af:menu in the 'menus' facet of the af:panelCollection.

      When navigate over the departments, the table of Employees changes according to the department shown in the form.
      Now open the 'Options' menu of the af:panelcollection and select the 'Export to Excel' menu. This exports the employees of the department into a file and sends it to the client. This all works OK.
      Now, if you click on the navigation button on the Department form the UI doesn't get updated any longer. The department and employees displayed stay the same until the next full page refresh (e.g. F5).

      Using JDev 11.1.1.6.0 this I can't reproduce this behavior. Here the navigation and refreshing the UI works OK even after exporting the data using the af:exportCollectionActionListener. The navigation on the master still takes place, only the UI doesn't reflect the changes.

      The attatched zip file contains two workspaces: ExportExcelApp11gR1 containing the 11.1.1.6.0 workspace and ExportExcelApp11gR2 containing the 11.1.2.3.0 workspace. Both are using the HR schema so you need to change the JDBC settings according to your environment.

      After loading the workspace comiple both projects and run the 'view1.jspx' page in the view controller project. Navigate over the departments and then export the employees table of on department. After that navigate to the next or previous department. Using 11.1.1.6.0 the new department and its employees are shown, using 11.1.2.3.0 the page shown the department and employees selected for export.

        Activity

        Hide
        Timo_Hahn added a comment - - edited

        The original bug was posted in this OTN thread: https://forums.oracle.com/forums/thread.jspa?threadID=2450458

        This behavior can be reproduced in JDev 11.1.2.x, so it's not new to 11.1.2.3.0!
        WORKAROUND: for JDev 11.1.2.x
        Add partial triggers from the navigation buttons to the panelForm showning the department (master)and to the panelCollection showing the employees (detail) and the page behaves like using JDev 11.1.1.6.0.

        Show
        Timo_Hahn added a comment - - edited The original bug was posted in this OTN thread: https://forums.oracle.com/forums/thread.jspa?threadID=2450458 This behavior can be reproduced in JDev 11.1.2.x, so it's not new to 11.1.2.3.0! WORKAROUND: for JDev 11.1.2.x Add partial triggers from the navigation buttons to the panelForm showning the department (master)and to the panelCollection showing the employees (detail) and the page behaves like using JDev 11.1.1.6.0.
        Hide
        Jan Vervecken added a comment -

        hi Timo

        Just wanted to confirm the behaviour you describe (using Export2ExcelBug.ZIP).
        Using JDeveloper 11.1.1.6.0 and ExportExcelApp11gR1.jws navigating, exporting and navigating again does not seem to be a problem.
        Using JDeveloper 11.1.2.3.0 and ExportExcelApp11gR2.jws after navigating and exporting, navigating again does not seem to be possible.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - hi Timo Just wanted to confirm the behaviour you describe (using Export2ExcelBug.ZIP). Using JDeveloper 11.1.1.6.0 and ExportExcelApp11gR1.jws navigating, exporting and navigating again does not seem to be a problem. Using JDeveloper 11.1.2.3.0 and ExportExcelApp11gR2.jws after navigating and exporting, navigating again does not seem to be possible. regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        Sorry gents, this one slipped me by.

        In investigating this issue today I found Support Note 1364261.1. Though the behaviour described by that note no longer throws ADF_FACES-60096 (which I believe has been fixed as per bug 9218151), the support note does say:

        "While downloading an excel-file via exportCollectionActionListener or after showing the page as printable via showPrintablePageBehavior....

        ....Cause: The ADF Faces query components do not support automatic PPR. If you set changeEventPolicy to be PPR globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none."

        This restriction as per the Support Note is documented in the Fusion Guide under the 3rd "Note" in section 25.2.1: http://docs.oracle.com/cd/E35521_01/web.111230/e16182/adf_lifecycle.htm#CIAIAEBD

        The conclusion I draw from this are exportCollectionActionListener & showPrintablePageBehavior are somehow related to query components, and they do not support automatic PPR, you need to handle this yourself in 11.1.2+.

        As such what I'll do is raise a doc bug for the Note in section 25.2.1 to expand it's definition of "ADF Faces query components" to include the two behaviour tags, and also direct the doc team to validate this with developers.

        As a side note of interest Steven Davelaar has a relating blog entry on automatic PPR: http://blogs.oracle.com/jheadstart/entry/jdev_11_1_2_differences. Note how Steven has detected the changing behaviour of the JSF lifecycle between 11gR1 vs 11gR2.

        Show
        chriscmuir added a comment - Sorry gents, this one slipped me by. In investigating this issue today I found Support Note 1364261.1. Though the behaviour described by that note no longer throws ADF_FACES-60096 (which I believe has been fixed as per bug 9218151), the support note does say: "While downloading an excel-file via exportCollectionActionListener or after showing the page as printable via showPrintablePageBehavior.... ....Cause: The ADF Faces query components do not support automatic PPR. If you set changeEventPolicy to be PPR globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none." This restriction as per the Support Note is documented in the Fusion Guide under the 3rd "Note" in section 25.2.1: http://docs.oracle.com/cd/E35521_01/web.111230/e16182/adf_lifecycle.htm#CIAIAEBD The conclusion I draw from this are exportCollectionActionListener & showPrintablePageBehavior are somehow related to query components, and they do not support automatic PPR, you need to handle this yourself in 11.1.2+. As such what I'll do is raise a doc bug for the Note in section 25.2.1 to expand it's definition of "ADF Faces query components" to include the two behaviour tags, and also direct the doc team to validate this with developers. As a side note of interest Steven Davelaar has a relating blog entry on automatic PPR: http://blogs.oracle.com/jheadstart/entry/jdev_11_1_2_differences . Note how Steven has detected the changing behaviour of the JSF lifecycle between 11gR1 vs 11gR2.
        Hide
        chriscmuir added a comment -

        Raised doc bug 15848158 as follows:

        In the JDev Fusion Guide 11.1.2.3.0, the 3rd "Note" under section "25.2.1
        What You May Need to Know About Partial Page Rendering and Iterator Bindings"
        states the following limitation on the ADF automatic PPR facility:

        "The ADF_Faces_query_components do not support automatic PPR. If you set
        changeEventPolicy to be ppr globally, any iterators associated with bindings
        for those components will have the changeEventPolicy attribute set to none."

        This same limitation is documented and referred to in Support Note 1364261.1.
        Yet the Support Note starts with a broader statement:

        "While downloading an excel-file via exportCollectionActionListener or after
        showing the page as printable via showPrintablePageBehavior....."

        ....neither of which components are known as "ADF Faces query components",
        they're behaviour tags/handlers you add to af:command controls.

        Via the ADF EMG issue http://java.net/jira/browse/ADFEMG-65 we've proven
        indeed there is a limitation for automatic PPR with
        exportCollectionActionListener & showPrintablePageBehavior, but the note in
        section 25.2.1 is not giving readers enough information to draw that
        conclusion because they don't know the exportCollectionActionListener &
        showPrintablePageBehavior and related to "ADF Faces query components".

        As such we should work to making this limitation clearer.

        For this doc bug can you:

        1) confirm with the ADF developers that these other ADF Faces tags, namely
        exportCollectionActionListener and showPrintablePageBehavior, are included in
        the limitation
        2) if yes, also try to understand what components fall under the category of
        "ADF Faces query components" in case there are other components that aren't
        obvious but are also applicable to this limitation
        3) and at the conclusion of 1 & 2 update the original note in the JDev Fusion
        Guide to be more specific then the generalized "ADF Faces query components"

        In addition on note "25.2.1 What You May Need to Know About Partial Page
        Rendering and Iterator Bindings" is says:

        "If you set changeEventPolicy to be ppr globally, any iterators associated
        with bindings for those components will have the changeEventPolicy attribute
        set to none."

        What's missing from this description is this a DT change or RT override? I
        believe it's a RT override but it's not clear from the text. Again please
        clarify with the developers the behavior here.

        Finally assuming it is a RT override, this leaves programmers guessing what
        they need to do to fix the issue. In this case they should define their own
        partialTriggers to perform PPR the "old school" way. Potentially we should
        also advise them of that in the note to give developers a clue of the easy
        fix."

        Show
        chriscmuir added a comment - Raised doc bug 15848158 as follows: In the JDev Fusion Guide 11.1.2.3.0, the 3rd "Note" under section "25.2.1 What You May Need to Know About Partial Page Rendering and Iterator Bindings" states the following limitation on the ADF automatic PPR facility: "The ADF_Faces_query_components do not support automatic PPR. If you set changeEventPolicy to be ppr globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none." This same limitation is documented and referred to in Support Note 1364261.1. Yet the Support Note starts with a broader statement: "While downloading an excel-file via exportCollectionActionListener or after showing the page as printable via showPrintablePageBehavior....." ....neither of which components are known as "ADF Faces query components", they're behaviour tags/handlers you add to af:command controls. Via the ADF EMG issue http://java.net/jira/browse/ADFEMG-65 we've proven indeed there is a limitation for automatic PPR with exportCollectionActionListener & showPrintablePageBehavior, but the note in section 25.2.1 is not giving readers enough information to draw that conclusion because they don't know the exportCollectionActionListener & showPrintablePageBehavior and related to "ADF Faces query components". As such we should work to making this limitation clearer. For this doc bug can you: 1) confirm with the ADF developers that these other ADF Faces tags, namely exportCollectionActionListener and showPrintablePageBehavior, are included in the limitation 2) if yes, also try to understand what components fall under the category of "ADF Faces query components" in case there are other components that aren't obvious but are also applicable to this limitation 3) and at the conclusion of 1 & 2 update the original note in the JDev Fusion Guide to be more specific then the generalized "ADF Faces query components" In addition on note "25.2.1 What You May Need to Know About Partial Page Rendering and Iterator Bindings" is says: "If you set changeEventPolicy to be ppr globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none." What's missing from this description is this a DT change or RT override? I believe it's a RT override but it's not clear from the text. Again please clarify with the developers the behavior here. Finally assuming it is a RT override, this leaves programmers guessing what they need to do to fix the issue. In this case they should define their own partialTriggers to perform PPR the "old school" way. Potentially we should also advise them of that in the note to give developers a clue of the easy fix."
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        On My Oracle Support I have been able to find (what you refer to):

        • note 1364261.1, "ADF_FACES-60003:Component with ID: X Not Registered For Active Data"
        • bug 9218151, "ADF_FACES-60003: COMPONENT WITH ID: PT12:PC2:CB11 NOT REGISTERED FOR ACTIVE DATA"
        • bug 15848158, "DOC BUG: CLARIFY LIMITATION VIA ON SUPPORT NOTE - EXPORTCOLLECTIONACTIONLISTENER"

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. On My Oracle Support I have been able to find (what you refer to): note 1364261.1, "ADF_FACES-60003:Component with ID: X Not Registered For Active Data" bug 9218151, "ADF_FACES-60003: COMPONENT WITH ID: PT12:PC2:CB11 NOT REGISTERED FOR ACTIVE DATA" bug 15848158, "DOC BUG: CLARIFY LIMITATION VIA ON SUPPORT NOTE - EXPORTCOLLECTIONACTIONLISTENER" regards Jan Vervecken
        Hide
        Timo_Hahn added a comment -

        Thanks for the update Chris!

        So it looks like my workaround is just the documented way to handle this situation

        However, I wonder if this is only a doc bug. The ppr works OK until you use the exportCollectionActionListener in the sample.
        The global setting for the ppr event handling in the adf-config.xml was turned off by myself. I had problem with this before with af:fileDownloadActionListeneron which you may add to the list for the doc bug (for reference http://tompeez.wordpress.com/2011/11/16/jdev-11-1-2-1-0-dealing-with-adf_faces-60003-error-component-with-id-r11cb1-not-registered-for-active-data/), so the first thing I do when building 11.1.2.x samples is to turn off the global setting.
        The iterators changeEventPolicy remained set to 'ppr' (I did not change this!) which results in the behavior seen.
        As I did not setup the sample myself (I got it from user509716) I assume that when I changed the global policy to 'none', the iterators setting were left as 'ppr'.

        The note in section 25.2.1 says:
        The ADF Faces query components do not support automatic PPR. If you set changeEventPolicy to be ppr globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none.

        Somehow table and form components reacts like the af:query component once a behavior tag fires an event, regardless of the iterators change event policy.

        I would call this unexpected.

        Regards,
        Timo

        Show
        Timo_Hahn added a comment - Thanks for the update Chris! So it looks like my workaround is just the documented way to handle this situation However, I wonder if this is only a doc bug. The ppr works OK until you use the exportCollectionActionListener in the sample. The global setting for the ppr event handling in the adf-config.xml was turned off by myself. I had problem with this before with af:fileDownloadActionListeneron which you may add to the list for the doc bug (for reference http://tompeez.wordpress.com/2011/11/16/jdev-11-1-2-1-0-dealing-with-adf_faces-60003-error-component-with-id-r11cb1-not-registered-for-active-data/ ), so the first thing I do when building 11.1.2.x samples is to turn off the global setting. The iterators changeEventPolicy remained set to 'ppr' (I did not change this!) which results in the behavior seen. As I did not setup the sample myself (I got it from user509716) I assume that when I changed the global policy to 'none', the iterators setting were left as 'ppr'. The note in section 25.2.1 says: The ADF Faces query components do not support automatic PPR. If you set changeEventPolicy to be ppr globally, any iterators associated with bindings for those components will have the changeEventPolicy attribute set to none. Somehow table and form components reacts like the af:query component once a behavior tag fires an event, regardless of the iterators change event policy. I would call this unexpected. Regards, Timo
        Hide
        chriscmuir added a comment -

        Agreed, thus why I put the emphasis in the doc team to refer back to the development team. There's obviously more to that limitation than just "ADF query components" so we'll let them sort it out, rather than spending time investigating all the ins and outs of the issue with the limited information we have to hand.

        Regardless we know the workaround (or in fact the correct setup), so that should be enough for development teams to proceed at this time.

        CM.

        Show
        chriscmuir added a comment - Agreed, thus why I put the emphasis in the doc team to refer back to the development team. There's obviously more to that limitation than just "ADF query components" so we'll let them sort it out, rather than spending time investigating all the ins and outs of the issue with the limited information we have to hand. Regardless we know the workaround (or in fact the correct setup), so that should be enough for development teams to proceed at this time. CM.
        Hide
        chriscmuir added a comment -

        There's really been no further progress internally on this, so at this stage I don't see this issue progressing. So I don't keep on tracking it, I'm going to close this issue at this time.

        CM.

        Show
        chriscmuir added a comment - There's really been no further progress internally on this, so at this stage I don't see this issue progressing. So I don't keep on tracking it, I'm going to close this issue at this time. CM.

          People

          • Assignee:
            Unassigned
            Reporter:
            Timo_Hahn
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: