Well, detachable models are mostly used for something you can relatively easily reconstruct. If you are building a complex object (multi-step wizard etc.) then you don't what to use a detachable object for it.
-Matej On 10/16/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
