cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [CForms] Repeater: why not hashCode for id?
Date Tue, 29 Mar 2005 06:09:47 GMT
Sylvain Wallez wrote:
> 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 :-)

After reading all suggestions this makes the most sense (for me) :-)

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------



Mime
View raw message