Let's say you have a Java object with 20 fields that's mapped to a
database using Hibernate. I don't see that there's much difference in
terms of memory utilization between using that object as the model and
creating a separate object with 20 fields to use as the model.
Following the principle of not repeating yourself, I'd say that
everything else being equal, it makes more sense to use the persistent
object. Of course there will always be fields that you don't want to
be set directly from the form, but you can use Brill's strategy of
wrapping the persistent object in another object that just contains
the fields for which you want to implement some extra logic.
There's a subtle difference between having the model reload the
persistent object every time and just keeping a hard reference to it
that is worth mentioning. If you keep a hard reference to the
persistent object, and you're using Hibernate's version or timestamp
feature, and you actually merge the object back into the session
rather than copy the fields to a newly-loaded object, then Hibernate
will be able to detect cases in which the user is trying to save edits
to a stale version of the object. This isn't always useful, but it
might be, depending on your requirements.
W
On Mar 1, 2009, at 5:09 AM, Johan Compagner wrote:
You shouldnt put that object directly in a CPM, but have a loadabled
detachable model in between. Because now you probably have that hib
object in the page between requests
On 28/02/2009, Stephen Swinsburg <s.swinsb...@lancaster.ac.uk> wrote:
Hi all,
I'm after your thoughts on the following method.
Suppose there is a wicket form with some fields that can map directly
to a simple Hibernate object, and hence a db table. Is it safe to
simply wrap this object in a CompoundPropertyModel and use it as the
backing model for the form?
Then in the onSubmit method, calling a method to get the object from
the form's model and saving it via Hibernate.
This does work fine, I'm just after any pitfalls that might happen
down the track. Very simple form here.
thanks.
S
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
