cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pope <>
Subject Re: [CForms] Repeater: why not hashCode for id?
Date Wed, 30 Mar 2005 08:40:05 GMT
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?


View raw message