myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Freedman (JIRA)" <>
Subject [jira] Created: (PORTLETBRIDGE-95) Trinidad GoLink/Faces CommandLink broken in bridge 2.0 if nav to another Faces view
Date Wed, 19 Aug 2009 21:15:15 GMT
Trinidad GoLink/Faces CommandLink broken in bridge 2.0 if nav to another Faces view

                 Key: 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.

View raw message