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
>