Carsten Ziegeler wrote:
This might be a stupid question, but why does the repeater need an own
identity attribute on the objects contained in the list? If I bind my
form to beans I have the hashCode of these objects which should be unique.
hashCodes are not supposed to be unique, even if the default implementation in Object /may/ use the memory address as hashCode!
But in all our samples we use an own "id" property. Could we simplify
this or is there something that prevents this? Or doesn't it make sense?
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.
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.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
