Java Doc for SelectionInList.java in  » Swing-Library » jgoodies-data-binding » com » jgoodies » binding » list » Java Source Code / Java DocumentationJava Source Code and Java Documentation

The SelectionInList uses three ValueModels to hold the list, the selection and selection index and provides bound bean properties for these models. You can access, observe and replace these ValueModels. This is useful to connect a SelectionInList with other ValueModels; for example you can use the SelectionInList's selection holder as bean channel for a PresentationModel. Since the SelectionInList is a ValueModel, it is often used as bean channel. See the Binding tutorial classes for examples on how to connect a SelectionInList with a PresentationModel.

This class also implements the ListModel interface that allows API users to observe fine grained changes in the structure and contents of the list. Hence instances of this class can be used directly as model of a JList. If you want to use a SelectionInList with a JComboBox or JTable, you can convert the SelectionInList to the associated component model interfaces using the adapter classes com.jgoodies.binding.adapter.ComboBoxAdapter and com.jgoodies.binding.adapter.AbstractTableAdapter respectively. These classes are part of the Binding library too.

The SelectionInList supports two list types as content of its list holder: List and ListModel. The two modes differ in how precise this class can fire events about changes to the content and structure of the list. If you use a List, this class can only report that the list changes completely; this is done by firing a PropertyChangeEvent for the list property. Also, a ListDataEvent is fired that reports a complete change. In contrast, if you use a ListModel it will report the same PropertyChangeEvent. But fine grained changes in the list model will be fired by this class to notify observes about changes in the content, added and removed elements.

If the list content doesn't change at all, or if it always changes completely, you can work well with both List content and ListModel content. But if the list structure or content changes, the ListModel reports more fine grained events to registered ListDataListeners, which in turn allows list views to chooser better user interface gestures: for example, a table with scroll pane may retain the current selection and scroll offset.

An example for using a ListModel in a SelectionInList is the asynchronous transport of list elements from a server to a client. Let's say you transport the list elements in portions of 10 elements to improve the application's responsiveness. The user can then select and work with the SelectionInList as soon as the ListModel gets populated. If at a later time more elements are added to the list model, the SelectionInList can retain the selection index (and selection) and will just report a ListDataEvent about the interval added. JList, JTable and JComboBox will then just add the new elements at the end of the list presentation.

If you want to combine List operations and the ListModel change reports, you may consider using an implementation that combines these two interfaces, for example ArrayListModel or LinkedListModel .

Important Note: If you change the ListModel instance, either by calling #setListModel(ListModel) or by setting a new value to the underlying list holder, you must ensure that the list holder throws a PropertyChangeEvent whenever the instance changes. This event is used to remove a ListDataListener from the old ListModel instance and is later used to add it to the new ListModel instance. It is easy to violate this constraint, just because Java's standard PropertyChangeSupport helper class that is used by many beans, checks a changed property value via #equals, not ==. For example, if you change the SelectionInList's list model from an empty list L1 to another empty list instance L2, the PropertyChangeSupport won't generate a PropertyChangeEvent, and so, the SelectionInList won't know about the change, which may lead to unexpected behavior.

This binding library provides some help for firing PropertyChangeEvents if the old ListModel and new ListModel are equal but not the same. Class com.jgoodies.binding.beans.ExtendedPropertyChangeSupport allows to permanently or individually check the identity (using ==) instead of checking the equity (using #equals). Class com.jgoodies.binding.beans.Model uses this extended property change support. And class ValueHolder uses it too and can be configured to always test the identity.

Since version 1.0.2 this class provides public convenience methods for firing ListDataEvents, see the methods #fireContentsChanged, #fireIntervalAdded, and #fireIntervalRemoved. These are automatically invoked if the list holder holds a ListModel that fires these events. If on the other hand the underlying List or ListModel does not fire a required ListDataEvent, you can use these methods to notify presentations about a change. It is recommended to avoid sending duplicate ListDataEvents; hence check if the underlying ListModel fires the necessary events or not. Typically an underlying ListModel will fire the add and remove events; but often it'll lack an event if the (selected) contents has changed. A convenient way to indicate that change is #fireSelectedContentsChanged. See the tutorial's AlbumManagerModel for an example how to use this feature.

The SelectionInList is partially defined for Lists and ListModels that contain null . Setting the selection to null on a SelectionInList that contains null won't set the selection index to the index of the first null element. For details see the SelectionInList.setSelection(Object) JavaDocs. This is because the current implementation interprets a null selection as unspecified, which maps better to a cleared selection than to a concrete selection index. Anyway, as long as you work with the selection index and selection index holder, such a SelectionInList will work fine. This is the case if you bind a SelectionInList to a JList or JTable. Binding such a SelectionInList to a JComboBox won't synchronize the selection index if null is selected.

Constraints: The list holder holds instances of List or ListModel , the selection holder values of type E and the selection index holder of type Integer . The selection index holder must hold non-null index values; however, when firing an index value change event, both the old and new value may be null. If the ListModel changes, the underlying ValueModel must fire a PropertyChangeEvent.
author:
   Karsten Lentzsch
version:
   $Revision: 1.36 $
See Also:   ValueModel
See Also:   List
See Also:   ListModel
See Also:   com.jgoodies.binding.adapter.ComboBoxAdapter
See Also:   com.jgoodies.binding.adapter.AbstractTableAdapter
See Also:   com.jgoodies.binding.beans.ExtendedPropertyChangeSupport
See Also:   com.jgoodies.binding.beans.Model
See Also:   com.jgoodies.binding.value.ValueHolder<
Parameters:
  E - > the type of the list elements and the selection

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types.

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types.

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types.

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction.

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction.

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction.

The PropertyChangeEvents delivered to the listener have the name set to "value".

If the list holder holds a ListModel, this SelectionInList listens to ListDataEvents fired by that ListModel, and forwards these events by invoking the associated #fireXXX method, which in turn notifies all registered ListDataListeners.

Changes to the list "write through" to the array, and changes to the array contents will be reflected in the list.
Parameters:
  listItems - the array of initial items
throws:
  NullPointerException - if listItems is null

Changes to the list "write through" to the array, and changes to the array contents will be reflected in the list.
Parameters:
  listItems - the array of initial items
Parameters:
  selectionHolder - holds the selection
throws:
  NullPointerException - if listItems orselectionHolder is null

Changes to the list "write through" to the array, and changes to the array contents will be reflected in the list.
Parameters:
  listItems - the array of initial items
Parameters:
  selectionHolder - holds the selection
Parameters:
  selectionIndexHolder - holds the selection index
throws:
  NullPointerException - if listItems,selectionHolder, or selectionIndexHolderis null

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types. What's the difference? ListModel provides all list access features required by the SelectionInList's. In addition it reports more fine grained change events, instances of ListDataEvents. In contrast developer often create Lists and operate on them and the ListModel may be inconvenient for these operations.

A convenient solution for this situation is to use the ArrayListModel and LinkedListModel classes. These implement both List and ListModel, offer the standard List operations and report the fine grained ListDataEvents.
Parameters:
  list - the initial list

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types. What's the difference? ListModel provides all list access features required by the SelectionInList's. In addition it reports more fine grained change events, instances of ListDataEvents. In contrast developer often create Lists and operate on them and the ListModel may be inconvenient for these operations.

A convenient solution for this situation is to use the ArrayListModel and LinkedListModel classes. These implement both List and ListModel, offer the standard List operations and report the fine grained ListDataEvents.
Parameters:
  list - the initial list
Parameters:
  selectionHolder - holds the selection
throws:
  NullPointerException - if selectionHolder is null

Note: Favor ListModel over List when working with the SelectionInList. Why? The SelectionInList can work with both types. What's the difference? ListModel provides all list access features required by the SelectionInList's. In addition it reports more fine grained change events, instances of ListDataEvents. In contrast developer often create Lists and operate on them and the ListModel may be inconvenient for these operations.

A convenient solution for this situation is to use the ArrayListModel and LinkedListModel classes. These implement both List and ListModel, offer the standard List operations and report the fine grained ListDataEvents.
Parameters:
  list - the initial list
Parameters:
  selectionHolder - holds the selection
Parameters:
  selectionIndexHolder - holds the selection index
throws:
  NullPointerException - if selectionHolder,or selectionIndexHolder is null

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction. If you provide an adapted bean property from a bean that extends the JGoodies Model class, you can enable the identity check feature in the methods #firePropertyChange by setting the trailing boolean parameter to true.
Parameters:
  listHolder - holds the list or list model
throws:
  NullPointerException - if listHolder is null

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction. If you provide an adapted bean property from a bean that extends the JGoodies Model class, you can enable the identity check feature in the methods #firePropertyChange by setting the trailing boolean parameter to true.
Parameters:
  listHolder - holds the list or list model
Parameters:
  selectionHolder - holds the selection
throws:
  NullPointerException - if listHolderor selectionHolder is null

Constraints: 1) The listHolder must hold instances of List or ListModel and 2) must report a value change whenever the value's identity changes. Note that many bean properties don't fire a PropertyChangeEvent if the old and new value are equal - and so would break this constraint. If you provide a ValueHolder, enable its identityCheck feature during construction. If you provide an adapted bean property from a bean that extends the JGoodies Model class, you can enable the identity check feature in the methods #firePropertyChange by setting the trailing boolean parameter to true.
Parameters:
  listHolder - holds the list or list model
Parameters:
  selectionHolder - holds the selection
Parameters:
  selectionIndexHolder - holds the selection index
throws:
  NullPointerException - if the listModelHolder,selectionHolder, or selectionIndexHolderis null
throws:
  IllegalArgumentException - if the listHolder is a ValueHolderthat doesn't check the identity when changing its value
throws:
  ClassCastException - if the listModelHolder contentsis neither a List nor a ListModel

The PropertyChangeEvents delivered to the listener have the name set to "value". In other words, the listeners won't get notified when a PropertyChangeEvent is fired that has a null object as the name to indicate an arbitrary set of the event source's properties have changed.

In the rare case, where you want to notify a PropertyChangeListener even with PropertyChangeEvents that have no property name set, you can register the listener with #addPropertyChangeListener, not #addValueChangeListener.
Parameters:
  l - the listener to add
See Also:   ValueModel

If the list holder holds a ListModel, this SelectionInList listens to ListDataEvents fired by that ListModel, and forwards these events by invoking the associated #fireXXX method, which in turn notifies all registered ListDataListeners. Therefore if you fire ListDataEvents in an underlying ListModel, you don't need this method and should not use it to avoid sending duplicate ListDataEvents.
See Also:   ListModel
See Also:   ListDataListener
See Also:   ListDataEvent
since:
   1.0.2

To avoid memory leaks it is recommended to invoke this method, if the list holder, selection holder, or selection index holder live much longer than this SelectionInList. Instead of releasing the SelectionInList, you typically make the list holder, selection holder, and selection index holder obsolete by releasing the PresentationModel or BeanAdapter that has created them before.

As an alternative you may use ValueModels that in turn use event listener lists implemented using WeakReference.

Basically this release method performs the reverse operation performed during the SelectionInList construction.
See Also:   PresentationModel.release
See Also:   BeanAdapter.release
See Also:   java.lang.ref.WeakReference
since:
   1.2

Since version 1.1 the selection will be restored after the list content change has been indicated. This is because some listeners may clear the selection in a side-effect. For example a JTable that is bound to this SelectionInList via an AbstractTableAdapter and a SingleSelectionAdapter will clear the selection if the new list has a size other than the old list.
Parameters:
  oldList - the old list content
Parameters:
  oldSize - the size of the old List content
Parameters:
  newList - the new list content
See Also:   javax.swing.JTable.tableChanged(javax.swing.event.TableModelEvent)