#1 may sound hard, and you might think you're missing out on some good 
Wicket abstraction, but it can work seamlessly. Once the objects are 
loaded, you shouldn't have to think about their database IDs again. An 
IModel implementation can do the grunt work internally:


You can even do a save in a base form class's onSubmit. Believe me, if 
#1 were the hard way I wouldn't be doing it!


Iman Rahmatizadeh wrote:
> Hi,
> AFAIK, there are three ways of implementing application transactions, 
> lazy loading, etc. stuff  with Wicket & Hibernate :
> 1 - The hard way, where you pass object ids, and load & save them in 
> each request cycle using a new session
> 2 - The detached object way, where you attach the old objects in each 
> request cycle to a new session
> 3 - Using long sessions, where you keep a session during multiple 
> requests and finally close when the unit of work is finished
> What I've seen in the examples & wicket-phonebook is mostly number 1. 
> However, as soon as you start working like 2 or 3, problems start. 
> Things seem to get too complicated in these two scenarios(Actually I'm 
> starting to think , despite its disadvantages, number 1 is better for a 
> component web framework).
> I would like to know if anybody has been working on these or has come up 
> with a convenient solution to the problems arising here.
> Iman

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