Package eu.webtoolkit.jwt

Class WAbstractItemModel

java.lang.Object
eu.webtoolkit.jwt.WObject
eu.webtoolkit.jwt.WAbstractItemModel
Direct Known Subclasses:
WAbstractListModel, WAbstractProxyModel, WAbstractTableModel, WItemModel, WStandardItemModel
public abstract class WAbstractItemModel extends WObject
An abstract model for use with JWt's view classes.

This abstract model is used by several JWt view widgets as data models.

It may model data for both tree-like and table-like view widgets. Data is therefore organized in a hierarchical structure of tables, where every item stores data and items in column 0 can be the parent of a nested table of data. Every data item is uniquely identified by their row, column and parent index, and items may be referenced using the helper class WModelIndex.

Each item may provide data for one or more roles, and indicate options using flags. The different roles can be used to model different aspects of an item (its text value, an icon, style class), or to hold auxiliary custom information. The flags provide information to the View on possible interactivity.

Side.Top level data have a null parent WModelIndex.

The data itself is of type Object, which can either be null, or be any type of data. Depending on the role however, view classes may expect certain types of data (e.g. numerical types for charts) or will convert the data to a string (e.g. for ItemDataRole.Display).

To implement a custom model, you need to reimplement the following methods:

A crucial point in implementing a hierarchical model is to decide how to reference an index in terms of an internal pointer (WModelIndex.getInternalPointer()). Other than the top-level index, which is special since it is referenced using an invalid index, every index with children must be identifiable using this object. For example, in the WStandardItemModel, the internal pointer points to the parent WStandardItem. For table models, the internal pointer plays no role, since only the toplevel index has children.

If you want to support editing of the model, then you need to indicate this support using a ItemFlag.Editable flag, and reimplement setData(). View classes will use the ItemDataRole.Edit to read and update the data for the editor.

When the model's data has been changed, the model must emit the dataChanged() signal.

Finally, there is a generic interface for insertion of new data or removal of data (changing the geometry), although this interface is not yet used by any View class:

Alternatively, you can provide your own API for changing the model. In either case it is important that you call the corresponding protected member functions which will emit the relevant signals so that views can adapt themselves to the new geometry.