[BINDING-82] Clarify interval of list model content changes Created: 08/Jan/06
Updated:
19/Jan/07 Resolved: 19/Jan/07
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
binding
core
1.0.3
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Task
karsten
Fixed
None
Not Specified
Issuezilla Id:
82
1.1.0
Priority:
Assignee:
Votes:
Major
binding-issues
0
Not Specified
Not Specified
Operating System: All
Platform: All
Description
The ListHolder, ListModelHolder, SelectionInList, SelectionInList2, and
SelectionInListModel fire content changes with an interval [0, Integer.MAX_VALUE].
It is questionable if this is the correct interval.
ListModel#fireContentsChanged describes the lower and upper bound as the bounds
of the new interval. Several ComboBoxModel implementations seem to break this
constraint if they fire the content change for an interval [-1, -1]. Note that
there's a special case in the BasicComboBoxUI's ListDataHandler that just asks
for [-1, -1]. All other ListDataListeners in the core don't use the bounds for
the update operations.
Also, the Binding implementation has been changed to use the wide interval,
because the AbstractTableAdapter uses the same interval when firing table model
content changes. And the TableModel seems to need the larger interval [0,
Integer.MAX_VALUE] (as described in a comment of the constructor
TableModelEvent(TableModel)).
Clarify how the interval should be. It seems to me, that it should provide the
bounds of the new interval. And the ComboBoxAdapter and TableModelAdapter shall
convert this interval as needed.
Comments
Comment by karsten [ 20/Jan/06 ]
The ListHolder, ListModelHolder, SelectionInList, SelectionInList2, and
SelectionInListModel implement ListModel and fire ListDataEvents.
If one of these ListModel implementations is converted using an
AbstractTableAdapter, the ListDataEvents are converted to TableModelEvents.
TableModelEvents are more fine grained than ListDataEvents.
In a table you can indicate different content changes:
1) structure, 2) row content, 3) row content plus no of rows.
In contrast, ListDataEvents content changes are only of type 2).
And actually the ListDataListeners in the core all handle
these changes as if they are 3) ignoring the first and last
index of the list content change.
The ListDataEvent fired by the above ListModel implementations shall be as
specific as needed and as general as necessary to safely describe potential
size changes, so the converted TableModelEvents indicates the right thing. In
version 1.0.3 this is achieved by always firing a ListDataEvent that will be
converted to a TableModelEvent of type 3), using an interval of [0,
Integer.MAX_VALUE].
I've added an ExtendedListDataEvent that adds information to the ListDataEvent
in case of a list change by storing the last index of the old list. This can be
used to check if the old and new list have the same size, or if the change is
more complex and includes a size change. This extended event can be translated
to a table content change of either type 2) or 3). An alternative would be
to translate the extended list change event to a table row insert/delete plus a
content change - the latter if necessary.
Here's how the JTable handles table model content changes:
in case 2) it just repaints the rows and keeps the selection,
in case 3) it repaints rows, updates the scrollbar and
clears the selection.
In addition, issue #85 shall always restore the selection, even in the cases
where a table had cleared it during the content change.
Just to be complete, ComboBoxModels use the ListDataEvent with interval [-1, -1]
for indicating a selection change. So there seems to be no need to change the
Binding's ComboBoxAdapter ListDataChangeHandler.
Comment by karsten [ 20/Jan/06 ]
Added a test that exhibits a problem when binding a SelectionInList to a JTable.
A draft is in the CVS that fixes the problem for bound tables. It uses an
extended list data event that provides additional information for content
changes that describe a list change by holding the last index of the old list.
That can be converted in the AbstractTableAdapter.
It is questionable, if this needs to be performed by the ComboBoxAdapter too, or
if we shall use two events in the case that the old and new list size differ.
Comment by karsten [ 20/Jan/06 ]
A list change in any of the list holding classes now fires a content change if
the old and new list have the same size, or a sequence of a remove and an add
event with the old and new interval resp. This seems to be safe events; and they
don't need any translation for any ListDataListener. And no interpretation of
the Swing spec is necessary.
The tests are now complete for all list holding classes. Fixes for all these
classes are already in the CVS.
Comment by karsten [ 24/Jan/06 ]
Changed the version to 1.0.3, closed.
Generated at Tue Feb 09 19:31:13 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.