[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman updated PORTLETBRIDGE-50:
------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.0.0
Status: Resolved (was: Patch Available)
As per changed spec, though the bridge continues to cache the view after the
action the restoration of this cache is now done via the Lifecyle (brdige's
viewhandler).
> Should Bridge use Lifecycle to RestoreView when restoring from memory cache?
> ----------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-50
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-50
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 2.0.0
> Reporter: Michael Freedman
> Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
> Attachments: jira_50.patch
>
>
> Currently the bridge manually restores the view in the first render after an
> action from memory (because the action can't save the view via faces). By
> manual I mean it merely sets the viewRoot to the view instead of calling
> Lifecycle.execute. This means the before/after restoreView phase listeners
> aren't called. About six months ago we added a hack to the spec/impl to
> require the before listener be called but withheld the after worried that
> running it twice in situation where action/render is usually in a single
> lifecycle could introduce problems. Well we hit use case where either
> neither of the two or both must be called but not one without the other
> (Faces demands this behavior).
> In discussing this it was raised that maybe we shouldn't have this manual
> process at all -- instead restore the view from memory when necessary as a
> natural part of the RestoreView phase of executing the lifecycle.
> We decided we should try this and determine if there are any side effects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.