Serialization and Form Models

[Matthew Welch <ma...@welchkin.net>]

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?

Re: Serialization and Form Models

[Matt Welch <ma...@welchkin.net>]

RaBe wrote:
> 
> I found Igors post on smart entity models very helpful on that matter:
> 
> http://wicketinaction.com/2008/09/building-a-smart-entitymodel/
> 
> basically, it attaches/detaches only if an Id is set (hence, it can be
> fetched
> from the backend)
> 
I had read that blog entry several times before but the significance of that
last part hadn't stuck with me. I adapted my entity model (using Neo4J not
Hibernate) and it looks like a good solution. Thanks for the pointer!

-- 
View this message in context: http://old.nabble.com/Serialization-and-Form-Models-tp27738959p27751745.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Serialization and Form Models

[Bert <ta...@gmail.com>]

I found Igors post on smart entity models very helpful on that matter:

http://wicketinaction.com/2008/09/building-a-smart-entitymodel/

basically, it attaches/detaches only if an Id is set (hence, it can be fetched
from the backend)

Bert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Serialization and Form Models

[Riyad Kalla <rk...@gmail.com>]

Matthew,

A quick absolute way to make sure those values are serialized is to use the
Java 'transient' keyword. But Wicket will be assuming that when a user hits
the Back button, that it can re-constitute the page from the serialized info
it has on disk, if it cannot, then yes you'll need a LoadableDetachable
model that can rebuild that expensive graph when demanded but you won't need
to persist it.

-R

On Sun, Feb 28, 2010 at 4:37 PM, Matthew Welch <ma...@welchkin.net> wrote:

> 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?
>