Ben Pope wrote:
Sylvain Wallez wrote:
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?
It all depends if you consider the repeater and the underlying collection to be part of the application data model or just a convenience container to show a set of independent objects to the user.
If it's a application-level collection, then the repeater should be considered just the same as finer-grained objects and locked as a whole, or checked for concurrent modification to prevent lost update if locking isn't an option.
If it's just a holder, then only individual rows are bound and saved to the underlying storage. Modified rows lead to an update and new rows lead to an insert. There is a problem though for deleted rows as the repeater does not track rows that have been deleted (and the corresponding IDs). But if the repeater is just a dumb container, deletion can occur as soon as the users triggers the delete action.
Does this answer your concerns, or did I missed something also?
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
