myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Freedman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Updated: (PORTLETBRIDGE-50) Should Bridge use Lifecycle to RestoreView when restoring from memory cache?
Date Tue, 09 Dec 2008 19:03:44 GMT

     [ 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.


Mime
View raw message