[jira] Reopened: (ADFFACES-393) ADFFACES-189 causes duplicate menu items to display the incorrect focus path. New optimization mentioned in that issue is needed.

["Gary Kind (JIRA)" <ad...@incubator.apache.org>]

     [ 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.