Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: EE-3.3.0.GA, 4.0.BETA, 4.0
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces3 trunk revision# 34488
All browsers
-
Assignee Priority:P2
Description
When adding a new autoCompleteEntry component to the top of a table the value of the top most autoCompleteEntry gets moved to the newly added autoCompleteEntry. See screenshot - The arrow indidicates pushing the 'Add' button to add a new row to the top of the table. Notice the Teaberry value has transferred to the newly added component. The same behaviour can not be seen when adding a row to the bottom of the table.
To reproduce:
1) Build / deploy test app located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/autoCompleteEntry
2) Navigate to: AutoCompleteEntry in Table (Add row to the top) test
3) Type a value autoCompleteEntry at the top of the table
4) Click Add button to add a new row
To reproduce:
1) Build / deploy test app located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/autoCompleteEntry
2) Navigate to: AutoCompleteEntry in Table (Add row to the top) test
3) Type a value autoCompleteEntry at the top of the table
4) Click Add button to add a new row
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.