I found another con with detachable is that if you are constructing a complex object graph _before_ putting it in the database you would have to do something cleverer... e.g. only detach if already persisted? We just stuck with non-detachable models.
Eelco Hillenius wrote: > >> Does this approach have any significant improvement over the former? and >> what could be the cons > > Like Alex said, look at LoadableDetachableModel for instance. You > don't have to discard right away; just do at at the end of the > request. It's what detachable is for. > > Pro detaching: less memory consumption per session, and you can avoid > lazy loading problems when you use e.g. Hibernate. Con: more database > traffic (if you don't cache these objects) and cpu usage (though very > very minimal). In general a pro is also that your objects are always > fresh. A general con when working in forms can be that you have to > persist changes right away or you'll lose them with the reload. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
