You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Gary Kind (JIRA)" <ad...@incubator.apache.org> on 2007/03/01 19:25:50 UTC
[jira] Created: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
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
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.
[jira] Resolved: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer resolved ADFFACES-393.
---------------------------------
Resolution: Fixed
Assignee: Adam Winer
Checked in patch from Gary Kind to the Trinidad trunk. Thanks.
> 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.
[jira] Reopened: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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.
[jira] Resolved: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer resolved ADFFACES-393.
---------------------------------
Resolution: Fixed
Checked in latest patch. Can't say I really know this code well enough to know if the patch is correct.
> 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.
[jira] Updated: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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 updated ADFFACES-393:
-------------------------------
Attachment: faces-1_2-070102.patch
> 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
> Attachments: faces-1_2-070102.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.
[jira] Reopened: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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:
--------------------------------
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.
[jira] Updated: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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 updated ADFFACES-393:
-------------------------------
Attachment: faces-1_2-070201.patch
Renamed attachment for the correct branch
> 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
> 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.
[jira] Updated: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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 updated ADFFACES-393:
-------------------------------
Attachment: faces-1_2-070201.patch
> 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, 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.
[jira] Updated: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Weßendorf updated ADFFACES-393:
----------------------------------------
Fix Version/s: 1.0.1-incubating-core-SNAPSHOT
Affects Version/s: 1.0.1-incubating-core-SNAPSHOT
> 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
> Affects Versions: 1.0.1-incubating-core-SNAPSHOT
> Reporter: Gary Kind
> Assigned To: Adam Winer
> Fix For: 1.0.1-incubating-core-SNAPSHOT
>
> Attachments: faces-1_2-070102.patch, faces-1_2-070201.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.
[jira] Updated: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "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 updated ADFFACES-393:
-------------------------------
Attachment: faces-1_2-070201.patch
> 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.
[jira] Resolved: (ADFFACES-393) ADFFACES-189 causes duplicate menu
items to display the incorrect focus path. New optimization mentioned in
that issue is needed.
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer resolved ADFFACES-393.
---------------------------------
Resolution: Fixed
Checked in patch.
A couple of notes for the future:
- All patches are going to be checked into the trunk first; even if you're using 1.2, it's much easier if you give us a patch relative to the trunk
- Your patches should ideally be relative to the current state of the trunk. Once the first patch was checked in, the second one shouldn't have been a complete patch, but an additive patch on top of the first.
Thanks!
> 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, 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.