Ya, that would work fine for the Seam case as well. The question is
though should these other projects that store things in the view
handle this stuff themselves or should these projects be able to
assume that if a value is put in the view it will not be modified by a
subsequent view? And should this guarantee apply to the RI by default
or should anything that stores an object in the view know that they
should clone the value because JSF does not guarantee that the value
is localized to the view it is stored in?
Mike
On 9/7/07, Adam Winer <adam.winer_at_oracle.com> wrote:
> Michael Youngstrom said the following on 9/7/07 10:52 AM PT:
> > I think rather than the special case of serializing UIViewRoot to
> > solve the Seam specific case I would prefer to try throwing this
> > specific issue back at Seam and force Seam to perhaps do a serialize
> > clone of it's "PAGE" scoped components at some safe time in the
> > lifecycle perhaps???
>
> That makes sense, and would be fairly straightforward:
>
> public class PageState
> {
> public Map<String, Object> getState();
>
> // Call at the end of the lifecycle
> public void dehydrate();
>
> // Called implicitly by the first call to getState()?
> protected void rehydrate();
>
> private char[] _serializedState;
> private transient Map<String, Object> _state;
> }
>
> -- Adam
>
> > Regardless, I guess my greater fear is with all the other
> > components/frameworks that are using the view under the assumption
> > that the values will be preserved/isolated with the view instance it
> > was stored in? (e.g. tomahawk:saveState, several Gravel components,
> > perhaps many more?).
> >
> > Mike
> >
> > On 9/7/07, Adam Winer <adam.winer_at_oracle.com> wrote:
> >> It sounds like the issue here is restricted to UIViewRoot
> >> attributes, as Seam is using the UIViewRoot as a bonus
> >> scope, right?
> >>
> >> What if UIViewRoot's saveState() implementation
> >> ran serialization on the results of its super.saveState()
> >> call, and we left alone the rest of the page's state?
> >>
> >> -- Adam
> >>
> >>
> >> Michael Youngstrom said the following on 9/7/07 9:40 AM PT:
> >>> It's looking like Serialization by default is going to lose. :)
> >>>
> >>> I just want to quickly make sure everyone is fully aware of the
> >>> problem this is solving. If I'm using server side state saving and
> >>> store an object in the view and in a later view modify that object
> >>> then all of the past views will be changed as well potentially causing
> >>> any number of hard to detect problems. Generally where immutable
> >>> stuff is stored in the view this is not a problem but with projects
> >>> like Seam using the view as an optional Scope this basically breaks
> >>> the scope's back button functionality which is the main reason why
> >>> someone would choose the PAGE scope over CONVERSATION scope in Seam.
> >>>
> >>> I personally can go either way on this issue because it is a rather
> >>> irregular issue and would cause significant performance problems if
> >>> turned on but I just want to make sure everyone is aware that this
> >>> issue is not just about parity between client and server state saving
> >>> but it's also about the correct behavior of data stored in the view.
> >>>
> >>> I agree though that some actual benchmark data would be useful.
> >>>
> >>> Mike
> >>>
> >>> On 9/7/07, Ed Burns <ed.burns_at_sun.com> wrote:
> >>>>>>>>> On Fri, 07 Sep 2007 11:32:22 +0200, "Jesse Alexander (KSFH 323)" <alexander.jesse_at_credit-suisse.com> said:
> >>>> JA> +1 from me too on not making the serialization default. Serialization is
> >>>> JA> way too costly.
> >>>>
> >>>> I cast my lot with Herr Jesse and Mr. Winer. I too would like to see a
> >>>> quantitative rationale, other than parity with the client side model.
> >>>>
> >>>> Also, Herr Jesse, don't say "+1 for not making..." It would be more
> >>>> clear to say "-1". Being an unrepentant email skimmer, when I see "+1"
> >>>> on a thread, I assume you agree with the proposal.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ed
> >>>>
> >>>>
> >>>> --
> >>>> | 156 Business Days until JavaOne 2008
> >>>> | ed.burns_at_sun.com | office: 408 884 9519 OR x31640
> >>>> | homepage: | http://purl.oclc.org/NET/edburns/
> >>>> | aim: edburns0sunw | iim: ed.burns_at_sun.com
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> > For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>