Johan,
I was trying to say, in a confused kind of way, that standard practice
is to back a form up with a bean of some kind, and that replacing that
bean with a persistent object wouldn't necessarily increase memory
utilization enough to bother with a detached model. On the other hand
if the persistent object had lots of references to other objects then
maybe detaching it would be a good idea. On the other hand, if the
form uses lots of AJAX, then it might not be worth reloading the
persistent object every time a request comes in. I suppose that the
best approach depends on the requirements.
W
On Mar 1, 2009, at 9:00 AM, Johan Compagner wrote:
i didnt say you have to have a different object.
I just say dont keep persistent objects in memory between requests.
Use
detachable for that.
The only exception i guess is when you create a new object that isnt
persisted yet to the db and you have some kind of wizard to fill it
up.
On Sun, Mar 1, 2009 at 14:56, Willis Blackburn <wbo...@panix.com>
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org