you could take a look at blog tutorial(wiki) or wicket iolite(wicket
stuff)...
cretzel wrote:
Hi,
I'm using Wicket together with Spring and Hibernate. And it's quite common,
I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel
which wraps the domain objects loaded with Hibernate, so that when the model
is detached it only holds the ID of the domain object and when its
load()-method is called it uses the ID to load the entity again from the
database (see
http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351
this post for an example). So one advantage of this pattern is that you
mainly never get into problems with detached entities
(LazyInitializingException and so on).
I only got one issue with this when using Spring's transaction support.
Suppose you are editing a domain object in a form and you submit the form
and it passes conversion and validation. Actually the changes you've made
have been written into the domain object when you are in onSubmit() for
example. Then in this situation these changes could easily get persistet to
the DB, even if you don't want them to at this point, e.g. because you want
to do some backend validation first. This can happen when Hibernate flushes
the session, for example before another query. The problem is that the
changes on the domain object are made outside of a transaction
[OpenSessionInViewFilter just opens a Session but doesn't start a
transaction].
An example:
Suppose you are editing an entity User, changing the username for example.
The onSubmit()-method could look like this:
onSubmit() {
// User with changed username, attached to the Session
User user = (User) getModelObject();
// Do a query. This will cause the changes made to user
// to be flushed to the DB
userService.getUsers();
// This method does some backend validation, possibly
// fails and the transaction is rolled back so that the
// changes should not be persisted
userService.saveUser(user);
}
After this, the changes could be persistent in the DB, although they
shouldn't because the validation in the backend failed which should have
rolled back the changes.
I hope I made clear the point.
What do you think?
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
