Carsten Ziegeler wrote:
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).Yes, sounds very good to me! But in this case you still need an identity
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?
property for replaying, or?
No, no identity at all! Since you replay the add/move/delete events, you just need to be able to remove/add items at specific positions. That means that the underlying collection should be a java.util.list or a dom Element.
But actually this can be even simpler and we don't need this record/replay thing :-)
Have a look at the dynamic template sample [1] and play with add/delete/move actions: each row has an ID which indicates the row's creation order. In the case of binding, we won't use exactly use this ID, but store in rows the position in the original collection as an attribute (e.g. "load-position").
When the repeater is saved, with this information it's easy to know where and how to bind its rows:
- if the "load-position" attribute exists, we bind to the corresponding object in the original collection,
- if the "load-position" attribute doesn't exist, that means the row is newly created, and we therefore create a new object to save it.
Row moves can be managed either by reordering the original collection or by creating a new collection to which objects will be added.
I like this more, and this has the potential to kill both the current (complicated) repeater binding and also the simple-repeater binding which becomes useless :-)
Sylvain
[1] http://localhost:8888/samples/blocks/forms/do-dynaRepeater.flow
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
