On 7/16/07, David Rosenstrauch <[EMAIL PROTECTED]> wrote:


My over-arching question at this point is:  Is it a requirement that a
model's target object be Serializable?


no


1) I tried to use a LoadableDetachableModel, partly as a way to avoid
making my data object Serializable.  But I'm wondering if that's not
correct.  Take for example a data object with gettters and setters for
the following fields:  id (int), foo (string), and bar (string).  Using
  LoadableDetachableModel, I can load the object on demand by id - and
so all I need to do is hold the id in the LoadableDetachableModel, and
can discard the object itself.  Thus the object doesn't need to be
serializable.


correct

However, lets say that a form submission by the user sets
the foo property to "foo", and bar property to "bar".  And let's say
further that "foo" is a valid value, but "bar" fails validation for some
reason - which will keep the user on the same form page.  In this case
won't a logic error result?  Since I'm not retaining (or serializing) my
instance of the data object, but rather loading it fresh from the
database each time, won't the "foo" value disappear?  Because when the
model needs to access the target object, it wouldn't be accessing a
"working" copy that had the value set to "foo", but rather a pristine
copy from the database that had an old value?


if validation fails the models are not updated, wicket will hold on to input
for you and redisplay it in the form. model updates are atomic in regard to
validation. so you are ok. the only thing to worry when using db backed
beans directly is locking. martijn has a  great example on how to handle
optimistic locking in the form on his blog.

2) How am I to handle the situation where I want to use a new (not yet
saved) instance of a data object as the target for a model?  Since the
object is not yet saved to the database, I can't use a
LoadableDetachableModel to load it fresh from the database every time.
And I can't just have the Model create a new instance each time either,
since it looks like repeated form submissions would wind up discarding
old values?  Is there any way to handle this situation without making my
model target serializable?


see above answer. you can use an ldm and in load() return new instance every
time. also consider creating a simple serializable bean for wicket form that
maps onto your object.

I'm fairly certain that I won't be deploying
Wicket with clustering (or at least not session clustering like with
Tomcat or Terracotta - I might cluster at the database level) so why
should I need to be forced to make all my data serializable?


there are other reasons why you need to make things serializable. first -
everything you put into httpsession - where wicket stores pages - must be
serializable. that is a requirement of the servlet spec.

second, wicket versions your objects to make backbutton work - that means
taking snapshots of objects - which means serializing them.

third, for efficiency wicket takes snapshots of pages and stores them to
disk - which you guessed it, requires serialization.

IModel is in part to allow the dto beans to not be serializable if you do
not want them to.

-igor
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to