shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stan Zapryanov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-371) prerender() executes for ViewController not rendered when navigating to page/bean not implementing ViewController
Date Sat, 23 Dec 2006 07:33:57 GMT
    [ http://issues.apache.org/struts/browse/SHALE-371?page=comments#action_39151 ] 
            
Stan Zapryanov commented on SHALE-371:
--------------------------------------

I observed the previously described behavior using shale-view.jar and shale-core.jar taken
from the shale-framework-20061220.zip that I downloaded from the nightly builds folder.

Looking at the code I see that whenever vr.resolveVariable(context, viewName)==null  then
the old viewName remains in the map because the method returns without setting a new viewName.
Note that the existing code nevertheless sets the new viewName even if vc !=null and vc is
NOT instance of ViewController. 

If I have to redefine the 'bug' I would say:
Navigating to a viewName for which the ViewControllerMapper returned mapping (name) is not
a valid JSF backing bean name would cause the prerender() to execute on the originating viewcontroller
bean.

So it seems the "bug" is observed when the viewControllerMapper returns a viewName for which
no backing bean is defined in faces-config.xml, disregarding if that bean is an instance of
viewcontroller or not. 

Simple scenario that would recreate the bug:
/folder1/bean1.jsp with h:commandLink going to /folder2/bean2.jsp 
with only folder1$bean1 backing bean defined in faces-config.xml

In that scenario, 'vc' remains null since no bean is defined/found  and the  setupViewController
method returns with 'folder1$bean1' still in the map. 
If folder12$bean2 was defined.. no matter if ViewController or not, the map would be containing
'folder12$bean2' as viewName at the end of the method, and prerender() would not be called
on 'folder1$bean1'.

Sorry I didn't get it quite right in my initial analysis.  Hopefully this time it should make
more sense.

Happy holidays!

> prerender() executes for ViewController not rendered when navigating to page/bean not
implementing ViewController
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: SHALE-371
>                 URL: http://issues.apache.org/struts/browse/SHALE-371
>             Project: Shale
>          Issue Type: Bug
>          Components: View
>    Affects Versions: 1.0.4-SNAPSHOT
>         Environment: Windows XP Pro, Tomcat 5.5, JDK 1.5.0_04, MyFaces
>            Reporter: Stan Zapryanov
>         Assigned To: Craig McClanahan
>             Fix For: 1.0.4-SNAPSHOT
>
>
> Not sure if this is a bug but it looks like it. 
> When navigating to a view (JSF) not implementing the ViewHandler framework from a ViewController
t(JSF/bean) that does, currently the prerender() method gets executed on the viewcontroller
that you are leaving (that won't get rendered). 
> My guess is that currently the old FacesConstants.VIEW_NAME_RENDERED entry remains in
the request map even though you are not rendering that viewconroller, and that triggers the
execution of prerender(). 
> Here is a suggested fix that appears to correct the problem described but I woudn't know
if it may brake other stuff.. :
> In the setupViewController() method of the ViewViewHandler class:
>             vc = vr.resolveVariable(context, viewName);
>             if (vc == null) {
>                 if (log.isDebugEnabled()) {
>                     log.debug(messages.getMessage("view.noViewController",
>                                                   new Object[] { viewId, viewName }));
>                 }
> // ---- START OF PROPOSED FIX 
>              context.getExternalContext().getRequestMap() .remove(FacesConstants.VIEW_NAME_RENDERED);

> //------END OF FIX-------
>                 return;
>             }
> Hope all makes sense and was helpful. 
> Cheers!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message