The problem with #1 is, first its a bit ugly, second you discard every 
persistent instance in each cycle (which is less efficient than #2 or 
#3), third you lose the advantages of working & passing POJO's between 
pages, Like you would call 'new ProfilePage(person.getId())' instead of 
'new ProfilePage(person))' and retrieve the person from database again 
in the profile page. As Nathan said, despite the disadvantages, it's the 
easiest and the most straight forward, and mostly adapted to the old MVC 
style of web programming.
With wicket, I would like to pass objects around to pages and methods, 
keep them in memory during the unit of work, and persist the changes at 
the end. The problem is I make a new Hibernate Session in each request 
cycle, so I have to re-attach the objects from the previous cycle to the 
new Hibernate Session each time (as in #2). This can get quite 
cumbersome and would easily get out of control.
With all that said , I guess I'm alone in this case and everybody agrees 
on using #1. Still if anybody has any experience with #2 or #3, I would 
be happy to know about it.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to