>From: "Richard Eggert" <[EMAIL PROTECTED]> > > I've been seeing weird problems with the invocation of @Prerender/prerender() > methods and the handling of request-scoped backing beans. > > I have a HTML-templated page rendered with Clay, and a corresponding > request-scoped backing bean annotated with @View. The backing bean has a > method > annotated with @Prerender that extracts a value from the request parameter > Map. > If the value has been set (via a URL parameter), the method uses it to > initialize a property of the backing bean. For postbacks to the page, the > value > is preserved using a Tomahawk saveState component. > > We have four developers each running their own development instance of > WebLogic > Server 9.2. For two of us, everything works perfectly. However, for the other > two, if the user loads the page twice in a row in different windows (or the > same > window) with different values for the URL parameter (or even the same value), > the @Prerender-annotated method is only called during the first load, and the > second instance of the page ends up with the same bean property values as the > first. A custom PhaseListener that has been set up to run before the > RENDER_RESPONSE phase in order to set values in the HTTP response header does > run both times, however. Additionally, loading a separate page before loading > this page the second time causes the @Prerender to work properly. > > In other words: > > Load pageA?param=1 in window 1. > Load pageA?param=2 in window 2. > Window 2 contains the same content as window 1, and checking the log reveals > that prerender was called for window 1 but not for window 2. > > Load pageA?param=1 in window 1. > Load pageB in window 3. > Load pageA?param=2 in window 2. > Window 2 contains content relevant to param=2, and checking the log reveals > that > prerender was called for both windows. > > Getting rid of the @View and @Prerender annonations and having the backing > bean > extend AbstractViewController had no effect, so the problem does not appear > to > be with shale-tiger's ViewController support (unless it is somehow > interfering > with the regular non-tiger ViewController support). > > Changing the STATE_SAVING_METHOD from "server" to "client" seems to fix the > problem. > > We are using MyFaces 1.1.4 and Shale 1.0.4. > > Any idea of what might be causing this behavior? >
It sounds like myfaces is restoring the view versus creating a new view. If you can use commandLink's for navigation, with navigation rules in the faces-config, the view will be recreated each time but that might not be an option. You might also try myfaces 1.1.5 with Shale nigthly. I believe there is some changes with state management in 1.1.5. > Rich Eggert > Member of Technical Staff > Proteus Technologies, LLC > http://www.proteus-technologies.com > > Gary