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 Mon, 28 Mar 2005 22:02:01 GMT
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).
>>
>>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?
>>
>>    
>>
>Yes, sounds very good to me! But in this case you still need an identity
>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


Mime
View raw message