[
https://issues.apache.org/jira/browse/TRINIDAD-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavitra Subramaniam updated TRINIDAD-1923:
------------------------------------------
Status: Patch Available (was: Open)
> CLONE -Issue in
> org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
> -----------------------------------------------------------------------------------
>
> Key: TRINIDAD-1923
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1923
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 2.0.0.3-core
> Environment: Mac OSX 10.5 with JVM 1.6.0_20.
> Running using ADF with JDeveloper 11.1.1.3.0
> Reporter: Pavitra Subramaniam
> Priority: Minor
>
> (Created this issue for fixing on trinidad trunk)
> I have been running the following example:
> http://adf-samples.googlecode.com/files/SampleTrainModelWithCustomAction.zip
> I just changed the view.train.TrainIdMenuModel class constructor to:
> public TrainIdMenuModel() {
> super();
> super.setMaxPathKey("MyMaxPathKey");
> }
> This is done to get a max visited node behavior. However when I click on the
> button 'Next' to navigate on the tree the nodes are not enabled as expected
> and the user has to click on 'Back' and then 'Next' twice to get the nodes
> enabled correctly.
> The example can be found in this blog entry:
> http://jobinesh.blogspot.com/2010/04/custom-model.html which is based on the
> ADF rich client demo
> (http://www.oracle.com/technology/products/adf/adffaces/11/doc/demo/adf_faces_rc_demo.html).
> The rich client demo can also be used to reproduce the issue.
> I accept that using a case test that relies in a whole framework like ADF is
> not ideal, but looking at the code of
> org.apache.myfaces.trinidad.model.ProcessUtils I think that the problem lies
> there. In the javadoc it is stated: "If set but the focus rowKey is after
> maxVisitedRowKey, set maxVisitedRowKey to the focus rowKey."
> However if we look at the code, we can see that this is not respected since
> the maxPath variable is 'cached' at the request map.
> If we assume that a MenuModel is going to be updated during the processing of
> a request BUT that the ProccessUtils.getMaxVisitedRowKey is invoked BEFORE
> the model is actually updated, the maxPath value will be calculated (and
> cached) using the non updated model. In particular the maxPath will be
> calculated incorrectly if the focusRowKey of the model is NOT updated before
> the first call to ProccessUtils.getMaxVisitedRowKey occurs during the
> request. After this, if the focusRowKey is updated in the model and
> ProccessUtils.getMaxVisitedRowKey is called (always being in the context of
> the same request), the contract will not be respected and the cached maxPath
> value will be returned (which can correspond to a node BEFORE the current
> focus node, which is wrong).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.