Models have been my achilles heel when it comes to Wicket. Not so much their
explicit use, but understanding whe they data they wrap around is serialized
or kept in session and when it's not. I was running some tests today to
experiment with just this subject. The domain object I was using in my tests
intentionally had one field that I could, as an option, populate with
unserializable value. This made it easy for me to determine when Wicket was
trying to store the object with the page, as it would throw an exception. I
created a page with a form to create new instances of this particular
object. I initialized the form with a CompoundPropertyModel wrapped around
my domain object. When I submitted the form and saved the object to my
backend store , I received a WicketNotSerializableException. I was initially
surprised by this, but after a few moments I realized (and correct me if I'm
wrong) that the model wasn't detachable and that when I saved it the
attribute I mentioned above was being populated with that unserializable
value, but wicket was trying to save the page (probably to disk) with the
model wrapped around the now unserializable object.

I guess this isn't a big deal, but what concerns me, and the reason I was
running these tests, was that some of the objects I'm working with have huge
data graphs attached to them. I don't want these huge objects stored in
memory or serialized with any of the pages to disk. Can a form be backed by
a detachable model? It certainly wouldn't be a "loadable" detachable model
for new objects that are to be created as there's nothing yet to load. If
one can back a form with detachable model, does that limit anything that you
can do with the form?

Reply via email to