#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:
http://databinder.net/wsvn/Databinder/databinder/trunk/src/main/java/net/databinder/models/HibernateObjectModel.java?op=file 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! Nathan 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
