[
https://issues.apache.org/jira/browse/TRINIDAD-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767915#action_12767915
]
Martin Koci edited comment on TRINIDAD-1600 at 10/21/09 5:35 PM:
-----------------------------------------------------------------
According to spec "The handleNavigation and getNavigationCase methods should
use the same logic to resolve a NavigationCase". That means if navigation case
is null, method handleNavigation will not call
facesContext.setViewRoot(newRoot) because no new viewId was resolved.
Saving and restoring viewMap is not ideal solution because there can be
listeners for PreDestroyViewMapEvent - we must avoid call to
facesContext.setViewRoot() which clears the view map and delivers event.
Spec says too: " If no navigation case is matched by a call to the
handleNavigation() method, this is an indication that the current view should
be redisplayed." I think we don't need a special solving for non-resolvable
navigation:
1) if outcome is not dialog -> delegate to wrapped NavigationHandler
2) if outcome is dialog -> try to find navigation case
(NavigationHandler.handleNavigation does the same) and:
2a) if navigation case was found do our special logic with viewRoot instead of
setting it on facesContext.setViewRoot() (this is the difference compared to
default handleNavigation implementation)
2b) if navigation case was not found log it for developer
ad 2b - spec says: " If none of the above steps found a matching
<navigation-case>, if ProjectStage is not Production render a message in the
page that explains that there was no match for this outcome." This
solves problem "navigation case does not exists" for us - when developer makes
a typo in a navigation rule, JSF in development stage informs him/her about it.
If you agree with this solution I will update this patch with implementation
(usage) of 2b
was (Author: markoc50):
According to spec "The handleNavigation and getNavigationCase methods
should use the same logic to resolve a NavigationCase". That means if
navigation case is null, method handleNavigation will not call
facesContext.setViewRoot(newRoot) because no new viewId was resolved.
Saving and restoring viewMap is not ideal solution because there can be
listeners for PreDestroyViewMapEvent
Spec says too: " If no navigation case is matched by a call to the
handleNavigation() method, this is an indication that the current view should
be redisplayed." I think we don't need a special solving for non-resolvable
navigation:
1) if outcome is not dialog -> delegate to wrapped NavigationHandler
2) if outcome is dialog -> try to find navigation case
(NavigationHandler.handleNavigation does the same) and:
2a) if navigation case was found do our special logic with viewRoot instead of
setting it on facesContext
2b) if navigation case was not found log it for developer
ad 2b - spec says: " If none of the above steps found a matching
<navigation-case>, if ProjectStage is not Production render a message in the
page that explains that there was no match for this outcome."
If you agree with this solution I will update this patch with implementation
of 2b.
> Trinidad2 - Dialog navigation clears View Scope
> -----------------------------------------------
>
> Key: TRINIDAD-1600
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1600
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 2.0.0-core
> Environment: Trinidad 2.0 branch, JSF RI 2.0.0RC2
> Reporter: Martin Koci
> Attachments: patch.txt, patch2.txt
>
>
> JSF 2.0 introduces new scope "View Scope" implemented with a Map
> UIViewRoot.viewMap. Spec also says that call FacesConfig.setViewRoot() clears
> that Map.
> Problem: Trinidad NavigationHandler uses method handleNavigation for
> detection if a dialog navigation will be performed - however that method
> creates new UIViewRoot and sets it to FacesContext -> clears view scope. If
> user places managed bean into view scope and starts a dialog: navigation on
> that view, bean is removed and new instance of the bean is created after
> dialog return.
> Solution: use new JSF 2.0 ConfigurableNavigationHandler API
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
