[
https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Kind reopened ADFFACES-393:
--------------------------------
I wanted to make sure I covered every possible case, so I created a real weird
scenario where quite a few of the menu items go to the same page (i.e.
duplicates), and links in buttons also go to those pages. I found one more
duplicate problem. This should be the last of them. The only difference
between this patch and the last is a one-line change in method
"setCurrentlyPostedNode()". This is called right at the beginning of the Render
Response Phase and will insure that the test at the beginning of
getFocusRowKey() (currentViewId == _prevViewId) will fail the first time
through. We want this for the case where we have selected and itemNode which
will navigate to the same page as the last itemNode we selected. If we simply
return because the focusViewId's have not changed, then we are returning the
wrong focusPath.
> ADFFACES-189 causes duplicate menu items to display the incorrect focus path.
> New optimization mentioned in that issue is needed.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: ADFFACES-393
> URL: https://issues.apache.org/jira/browse/ADFFACES-393
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Reporter: Gary Kind
> Assigned To: Adam Winer
> Attachments: faces-1_2-070102.patch, faces-1_2-070201.patch,
> faces-1_2-070201.patch
>
>
> In ADFFACES-189, a performance optimization was removed because a change in
> the ADF Faces architecture caused the optimization to be incorrect and
> resulted in erroneous focus paths being returned by
> XMLMenuModel.getFocusRowKey(). In that issue, a new optimization is
> mentioned which works but had to be tested.
> The optimization was originally put in because XMLMenuModel.getFocusRowKey()
> is called many times during the Process Validations Phase and the Render
> Response Phase -- the result always being the same as the first time it is
> called during each phase.
>
> Code that returns the correct focus path for duplicate nodes in the
> XMLMenuModel node tree actually depends on this optimization. Removing the
> previous optimization broke this.
>
> During each phase, as explained below, the same viewId is passed in. To
> prevent unnecessary looking up of the focus path each time, the previous
> focus path is returned after the first call in each phase.
> ** Process Validations Phase:
> During the Process Validations Phase, the prevViewId is initially null (gets
> set to this at the start of each Request). The first time getFocusRowKey is
> called, the currentViewId is that of the node we are navigating "from" during
> the Request. This is stored in prevViewId. Because the currentViewId is not
> equal to the prevViewId, the "from" node is looked up, its focus path stored
> in prevFocusPath, and the focus path is returned. On subsequent calls during
> the Process Validations Phase, the currentViewId is always that of the "from"
> node, the currentViewId is equal to the prevViewId, and so we simply return
> prevFocusPath.
> ** Render Response Phase:
> During the Render Response Phase, the prevViewId is initially that of the
> "from" node. The first time getFocusRowKey is called, the currentViewId is
> that of the node we are navigating "to" during the Request. This is stored
> in prevViewId.
> Because the currentViewId is not equal to the prevViewId, the "to" node is
> looked up, its focus path stored in prevFocusPath, and the focus path is
> returned. On subsequent calls during the Render Response Phase, the
> currentViewId is always that of the "to" node, the currentViewId is equal to
> the prevViewId, and so we simply return prevFocusPath.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
