Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <60084727.1250716515144.JavaMail.jira@brutus>
Date: Wed, 19 Aug 2009 14:15:15 -0700 (PDT)
From: "Michael Freedman (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Created: (PORTLETBRIDGE-95) Trinidad GoLink/Faces
 CommandLink broken in bridge 2.0 if nav to another Faces view
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Trinidad GoLink/Faces CommandLink broken in bridge 2.0 if nav to another Faces view
-----------------------------------------------------------------------------------

                 Key: PORTLETBRIDGE-95
                 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-95
             Project: MyFaces Portlet Bridge
          Issue Type: Bug
          Components: Impl
    Affects Versions: 2.0.0-alpha, 2.0.0
            Reporter: Michael Freedman
            Assignee: Michael Freedman


Trinidad GoLinks and Faces CommandLink's that reference another Faces view ultimately are encoded as actionURLs but submitted via GETs (a hefs).  This means when the action is processed a VIEW_STATE param isn't passed to the action -- leaving us in position in which the render that follows this action has a cached view but no (preserved) VIEW_STATE param.  Since this render restores the view manually but then calls lifecycle.execute we get triupped up in Mojarra's lifecycle (restoreView handler) that sets responseComplete if the UIViewRoot has already been restored AND its not a postback (no VIEW_STATE param).  With responseCompelte set, the bridge skips calling lifecycle.render -- thus the page generates no markup.

The fix is to detect that the action is called with no VIEW_STATE param and to preserve a placeholder/dummy one so that the following render works.  This should be safe as the VIEW_STATE param is updated at the end of render with the one that results from having saved the view -- thus overwriting the palceholder at a time when we remove the view from the cache.

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