My personal view is that we should not be including this as a standard feature of the core. It just adds extra jar dependencies, increases the size of the web application and so on. I'm personally more than happy with using the standard serialization mechanism provided by my application server vendor.
Serialzation is a messy thing to deal with and I think that a certain discipline and design ethic is forced on you by having to implement Serializable and deal with the differences between transient and persistent fields. If you want to design efficient web applications then you have to be aware of the issues involved in this. Wicket can hide it for simpler applications but as soon as you start growing to servers supporting session clustering and recovery then you have to understand a bit more about what is going on and make some important design decisions.
However, I would be +1 for providing XStreamPageState and other Xstream support as an optional implementation in the contrib package.
Regards,
Chris
>
>
>
> if xstream doesn't have downsides and is more efficient and we don't
> care about vm requirements, we could use xstream for undo cloning
> operations. then if we provided XStreamPageState, you
> wouldn't have to
> make anything serializable. (uh... i think). xml seems like
> a terribly
> verbose format though. i'm concerned about memory impact...
>
> Gili wrote:
>
> >On Tue, 08 Mar 2005 08:32:18 -0800, Jonathan Locke wrote:
> >
> >
> >
> >>if gili wants to go test our new PageState mechanism by
> making a nice
> >>subclass of PageState using xstream (XStreamPageState?),
> that might make
> >>a really nice contrib or extensions class...
> >>
> >>
> >
> > Before I do I want to make sure I have a better
> understanding of how
> >far I can go to serialize as little as possible with the web
> container
> >and handling the rest with XStream. My main concern is for
> >user-classes: users should not have to worry about serialization or
> >no-arg constructors and I simply want to give them the
> option of doing
> >so. So it would be nice if say we'd still have to persist
> Wicket using
> >the web container but everything else could be handled "in-house" by
> >Wicket using XStream.
> >
> >Gili
> >
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real
> >users. Discover which products truly live up to the hype.
> Start reading
> >now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >Wicket-develop mailing list [email protected]
> >https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
> >
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users. Discover which products truly live up to the
> hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
