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] Updated: (SHALE-455) isPostBack() claims falsely TRUE in the View bean being forwarded to
Date Sun, 15 Jul 2007 08:45:11 GMT

     [ https://issues.apache.org/struts/browse/SHALE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stan Zapryanov updated SHALE-455:
---------------------------------

    Description: 
In the following scenario:

Postback processed by page A, which then navigates to page B: 
Backing bean for page A is instantiated during Restore View phase, which notices that there
is previous state to restore. 
The setPostback(true) and init() methods on your backing bean for page A are called. 

(Assuming that the correct behavior of ShaleView is to have the backing bean for page B actually
return FALSE on isPostback() (in contrast to page A's bean that returns TRUE) )

....
Problem:

 It also appears that isPostack() returns TRUE on page B's viewbean (inappropriately) since
the request attribute remains in context.getExternalContext().getRequestMap() and bean B is
created by the following code in AbstractViewController constructor:

    public AbstractViewController() {

        FacesContext context = FacesContext.getCurrentInstance();
        if ((context != null)
            && context.getExternalContext().getRequestMap().containsKey(FacesConstants.VIEW_POSTBACK))
{
            setPostBack(true);
        }

    }

Suggested FIX In ViewViewHandler :

    private void setupViewController(FacesContext context, UIViewRoot view,
                                     String viewId, boolean postBack) {

        // Is there actually a view for us to procses?
        if (view == null) {
            return;
        }

        // Cache the postback flag so that it can be used inside
        // the AbstractViewcontroller implementation
        if (postBack) {
            context.getExternalContext().getRequestMap().
              put(FacesConstants.VIEW_POSTBACK, Boolean.TRUE);
        } 
//FIX STARTS HERE
else {
            context.getExternalContext().getRequestMap().
            remove(FacesConstants.VIEW_POSTBACK);        	
        }
//FIX ENDS HERE

I hope I'm not misinterpreting the overall behavior..

  was:
In the following scenario:

Postback processed by page A, which then navigates to page B: 
Backing bean for page A is instantiated during Restore View phase, which notices that there
is previous state to restore. 
The setPostback(true) and init() methods on your backing bean for page A are called.

....

 IT also seams that the setPostack(true) is called on page B (inappropriately) since the request
attribute remains in the map and bean B is created by the following code in the constructor:


In ViewViewHandler :

    private void setupViewController(FacesContext context, UIViewRoot view,
                                     String viewId, boolean postBack) {

        // Is there actually a view for us to procses?
        if (view == null) {
            return;
        }

        // Cache the postback flag so that it can be used inside
        // the AbstractViewcontroller implementation
        if (postBack) {
            context.getExternalContext().getRequestMap().
              put(FacesConstants.VIEW_POSTBACK, Boolean.TRUE);
        } 
//FIX STARTS HERE
else {
            context.getExternalContext().getRequestMap().
            remove(FacesConstants.VIEW_POSTBACK);        	
        }
//FIX ENDS HERE


> isPostBack() claims falsely TRUE in the View bean being forwarded to
> --------------------------------------------------------------------
>
>                 Key: SHALE-455
>                 URL: https://issues.apache.org/struts/browse/SHALE-455
>             Project: Shale
>          Issue Type: Bug
>          Components: View
>    Affects Versions: 1.0.4
>         Environment: not relevant
>            Reporter: Stan Zapryanov
>
> In the following scenario:
> Postback processed by page A, which then navigates to page B: 
> Backing bean for page A is instantiated during Restore View phase, which notices that
there is previous state to restore. 
> The setPostback(true) and init() methods on your backing bean for page A are called.

> (Assuming that the correct behavior of ShaleView is to have the backing bean for page
B actually return FALSE on isPostback() (in contrast to page A's bean that returns TRUE) )
> ....
> Problem:
>  It also appears that isPostack() returns TRUE on page B's viewbean (inappropriately)
since the request attribute remains in context.getExternalContext().getRequestMap() and bean
B is created by the following code in AbstractViewController constructor:
>     public AbstractViewController() {
>         FacesContext context = FacesContext.getCurrentInstance();
>         if ((context != null)
>             && context.getExternalContext().getRequestMap().containsKey(FacesConstants.VIEW_POSTBACK))
{
>             setPostBack(true);
>         }
>     }
> Suggested FIX In ViewViewHandler :
>     private void setupViewController(FacesContext context, UIViewRoot view,
>                                      String viewId, boolean postBack) {
>         // Is there actually a view for us to procses?
>         if (view == null) {
>             return;
>         }
>         // Cache the postback flag so that it can be used inside
>         // the AbstractViewcontroller implementation
>         if (postBack) {
>             context.getExternalContext().getRequestMap().
>               put(FacesConstants.VIEW_POSTBACK, Boolean.TRUE);
>         } 
> //FIX STARTS HERE
> else {
>             context.getExternalContext().getRequestMap().
>             remove(FacesConstants.VIEW_POSTBACK);        	
>         }
> //FIX ENDS HERE
> I hope I'm not misinterpreting the overall behavior..

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message