Sylvain Wallez wrote: >> >>Yepp, that's true - but usually for your own business objects you know >>if hashCode is unique or not. >> >> > > > Hmm... *you* know, but I don't think all people take care of that! > Yes, that's true. Now, I don't want that the repeater always relies on hashCode but perhaps as a default - if no identity is given for example. And everything else stays the same. But perhaps your suggestions below are even better!
> > No, the problem for me was time and lack of real need ;-) > :) > Now there may be a problem if the objects used to load the form need to > different from those used to save it, either because they're big (and we > don't want them to stay around until continuation expiration) or because > of transactional needs (e.g. Hibernate objects attached to different > sessions). > > Another idea I suggested (just comes back to my mind) is to have the > repeater record the row additions/moves/deletions occuring since the > last time it was loaded by the binding, and then have the binding replay > these events on the target collection on save. This avoids keeping the > objects around and also handles row deletions which my other proposal > doesn't. > > That may be a better solution. WDYT? > Yes, sounds very good to me! But in this case you still need an identity property for replaying, or? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
