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
What if the underlying structure can have different (previous) rows removed from it between when you load the model and save it back?
Obviously you would usually lock the back end model, but you should only need to lock the rows that you have retrieved, and deal with unique IDs in a common manner.
If you're just playing back positions and actions over the model, then you prevent simultaneous access to the data. Either that or you just push the complications into the users model.
I suppose you could just tag old rows as dead, instead of removing them. And then clean up when nothing is locked.
Having the identity solved this problem. Or have I missed something?
Ben
