Arturo Zambrano added a comment - 25/Apr/13 9:54 AM - edited Committed fix at revision 34530. The issue was cause because the 'text' component field, which acts as a secondary value property, was always being rendered. Since 'text' is just a component field and not a property, there's no way to bind its value to a property in a backing bean, so the component always retained the same value for this field. It seems that when adding rows to the top, the components at the top are actually the same instances they were before those rows were added. Then, the iterative container reassigns the values, according to the underlying model, but other properties of the component THAT AREN'T BOUND TO A BEAN are retained the way they are, as in the case of the 'text' field. Many different approaches were attempted before figuring out the real situation. Eventually, upgrading the 'text' @Field to a @Property in the Meta class, and binding its value to another property in the underlying data object (Employee in the test app), revealed that if the property is bound, then it is updated correctly, since the actual 'value' property was always updated correctly, but since the component used to render the 'text' property only, it appeared as if the value of the component at the top got added to the newly added row. So, this was fixed by deciding when to render the actual 'value' property and by deciding when to clear the 'text' field. This fix incidentally fixes the issue of not being able to programmatically change the (displayed) value of the component.

Arturo Zambrano added a comment - 25/Apr/13 10:01 AM Testing notes: Just test the specific use case and run all regression tests to see if these changes caused any regressions.