Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Yepp, that's true - but usually for your own business objects you knowCarsten Ziegeler wrote:
hashCodes are not supposed to be unique, even if the default implementation in Object /may/ use the memory address as hashCode!
if hashCode is unique or not.
Hmm... *you* know, but I don't think all people take care of that!
Personally, I find this repeater binding stuff very complicated. I cases where all data of the underlying application data are displayed in a form, I use the simple-repeater binding that first destroys the collection before recreating it from scratch. Up to now, it has fulfilled 80% of my needs.
Ah, didn't know the simple-repeater binding, but in my use-cases I can't destroy the objects and recreate them :(
A suggestion I made once to simplify the repeater binding when using simple-repeater isn't possible is to store the objects as attributes of the rows they are bound to during load (see widget.{get/set}Attribute()), and later use that information to recreate the collection on save. I guess this is similar to what you suggest, except it would use strict pointer equality (i.e. '==') instead of hascodes which may not be unique.Yes, right. I find it really annoying to add an identity property just
because the repeater requires it. This means that the forms framework
has an influence on my data model and that is simply bad.
So are there any problems with implementing your suggestion?
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?
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
