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 14:48:20 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>Carsten Ziegeler wrote:
>>
>>
>>hashCodes are not supposed to be unique, even if the default 
>>implementation in Object /may/ use the memory address as hashCode!
>>
>>    
>>
>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!

>>Personally, I find this repeater binding stuff very complicated. I cases 
>>where all data of the underlying application data are displayed in a 
>>form, I use the simple-repeater binding that first destroys the 
>>collection before recreating it from scratch. Up to now, it has 
>>fulfilled 80% of my needs.
>>    
>>
>Ah, didn't know the simple-repeater binding, but in my use-cases I can't
>destroy the objects and recreate them :(
>
>  
>
>>A suggestion I made once to simplify the repeater binding when using 
>>simple-repeater isn't possible is to store the objects as attributes of 
>>the rows they are bound to during load (see 
>>widget.{get/set}Attribute()), and later use that information to recreate 
>>the collection on save. I guess this is similar to what you suggest, 
>>except it would use strict pointer equality (i.e. '==') instead of 
>>hascodes which may not be unique.
>>    
>>
>Yes, right. I find it really annoying to add an identity property just
>because the repeater requires it. This means that the forms framework
>has an influence on my data model and that is simply bad.
>So are there any problems with implementing your suggestion?
>  
>

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?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message