> Thanks for your reply. In deed, I declared the LoadableDetachableModel > inside the IDataProvider. So the bottom line of your post is, that it is > serialized anyway altogether?
That data provider will be stored as component state of your repeater. Anything on your page will be serialized. We provide things like detachable models to minimize that at the end of a request, right before it might be serialized. Also note that whether there is any serialization done depends on the session store you use, and any serialization is only done either for back button support or to synchronize across a cluster if you use that. > Are there some docs for wicket serialization around? As I figured out, > wicket likes serialization. But so far I wasn't able to find some docs > explaining what is serialized and when. If you - or somebody else - would > give me the right pointers, I'd start a new page in the wiki, that > especially talks about what is serialized and when, what should be > transient, how to troubleshoot/debug/optimize serialization, and so forth. Not really, because it depends largely on your configuration. The default one - SecondLevelCacheSessionStore - stores n older page instances/ versions to 'second level cache' (by default a file per session in your temp dir) using serialization for back button support. And that's pretty much it. You can trace the calls to Objects.objectToByteArray /byteArrayToObject/ cloneObject/ cloneModel to get an idea of where Wicket uses serialization. Eelco Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
