[
https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Kind reopened ADFFACES-393:
--------------------------------
A boundary case is not working correctly -- selecting any non-duplicate node
after selecting a duplicate, results in incorrect rendering of the focus path
> 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
>
>
> 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.
