cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [CForms] Repeater: why not hashCode for id?
Date Wed, 30 Mar 2005 08:55:41 GMT
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


Mime
View raw message