Model subclasses need to provide implementations of many of the virtual functions defined in the QAbstractItemModel base class. The number of these functions that need to be implemented depends on the type of model - whether it supplies views with a simple list, a table, or a complex hierarchy of items. Models that inherit from QAbstractListModel and QAbstractTableModel can take advantage of the default implementations of functions provided by those classes. Models that expose items of data in tree-like structures must provide implementations for many of the virtual functions in QAbstractItemModel.
model子类需要实现QAbstractItemModel的很多虚函数。需要实现的函数要看使用什么类型的数据，list，table还是复杂的层次（hierarchy ）的结构。QAbstractListModel and QAbstractTableModel默认实现了一些虚函数，树形结构就需要实现QAbstractItemModel的很多函数。
The functions that need to be implemented in a model subclass can be divided into three groups:
- Item data handling: All models need to implement functions to enable views and delegates to query the dimensions of the model, examine items, and retrieve data.
- Navigation and index creation: Hierarchical models need to provide functions that views can call to navigate the tree-like structures they expose, and obtain model indexes for items.
- Drag and drop support and MIME type handling: Models inherit functions that control the way that internal and external drag and drop operations are performed. These functions allow items of data to be described in terms of MIME types that other components and applications can understand.
需要实现的函数可以分为三类：
- 数据处理
- 浏览和索引创建
- 拖拽和MIME类型处理
For more information, see the "Item View Classes" Chapter of C++ GUI Programming with Qt 4.
Item data handling
Models can provide varying levels of access to the data they provide: They can be simple read-only components, some models may support resizing operations, and others may allow items to be edited.
只读，大小可变，可编辑三种层次。
Read-Only access
To provide read-only access to data provided by a model, the following functions must be implemented in the model's subclass:
| flags() | Used by other components to obtain information about each item provided by the model. In many models, the combination of flags should include Qt::ItemIsEnabled and Qt::ItemIsSelectable. |
| data() | Used to supply item data to views and delegates. Generally, models only need to supply data for Qt::DisplayRole and any application-specific user roles, but it is also good practice to provide data for Qt::ToolTipRole, Qt::AccessibleTextRole, andQt::AccessibleDescriptionRole. See the Qt::ItemDataRole enum documentation for information about the types associated with each role. |
| headerData() | Provides views with information to show in their headers. The information is only retrieved by views that can display header information. |
| rowCount() | Provides the number of rows of data exposed by the model. |
These four functions must be implemented in all types of model, including list models (QAbstractListModel subclasses) and table models (QAbstractTableModel subclasses).
flags，data，headerData，rowCount所有model都要实现。
Additionally, the following functions must be implemented in direct subclasses of QAbstractTableModel and QAbstractItemModel:
columnCount在QAbstractTableModel and QAbtractItemModel子类必须实现。QAbtractListModel不要。
| columnCount() | Provides the number of columns of data exposed by the model. List models do not provide this function because it is already implemented in QAbstractListModel. |
Editable items
Editable models allow items of data to be modified, and may also provide functions to allow rows and columns to be inserted and removed. To enable editing, the following functions must be implemented correctly:
| flags() | Must return an appropriate combination of flags for each item. In particular, the value returned by this function must include Qt::ItemIsEditable in addition to the values applied to items in a read-only model. |
| setData() | Used to modify the item of data associated with a specified model index. To be able to accept user input, provided by user interface elements, this function must handle data associated with Qt::EditRole. The implementation may also accept data associated with many different kinds of roles specified by Qt::ItemDataRole. After changing the item of data, models must emit the dataChanged() signal to inform other components of the change. |
| setHeaderData() | Used to modify horizontal and vertical header information. After changing the item of data, models must emit theheaderDataChanged() signal to inform other components of the change. |
Resizable models
大小可变。
All types of model can support the insertion and removal of rows. Table models and hierarchical models can also support the insertion and removal of columns. It is important to notify other components about changes to the model's dimensions both before and after they occur. As a result, the following functions can be implemented to allow the model to be resized, but implementations must ensure that the appropriate functions are called to notify attached views and delegates:
| insertRows() | Used to add new rows and items of data to all types of model. Implementations must call beginInsertRows() beforeinserting new rows into any underlying data structures, and call endInsertRows() immediately afterwards. |
| removeRows() | Used to remove rows and the items of data they contain from all types of model. Implementations must callbeginRemoveRows() before inserting new columns into any underlying data structures, and call endRemoveRows()immediately afterwards. |
| insertColumns() | Used to add new columns and items of data to table models and hierarchical models. Implementations must callbeginInsertColumns() before rows are removed from any underlying data structures, and call endInsertColumns() immediately afterwards. |
| removeColumns() | Used to remove columns and the items of data they contain from table models and hierarchical models. Implementations must call beginRemoveColumns() before columns are removed from any underlying data structures, and callendRemoveColumns() immediately afterwards. |
Generally, these functions should return true if the operation was successful. However, there may be cases where the operation only partly succeeded; for example, if less than the specified number of rows could be inserted. In such cases, the model should return false to indicate failure to enable any attached components to handle the situation.
The signals emitted by the functions called in implementations of the resizing API give attached components the chance to take action before any data becomes unavailable. The encapsulation of insert and remove operations with begin and end functions also enable the model to managepersistent model indexes correctly.
Normally, the begin and end functions are capable of informing other components about changes to the model's underlying structure. For more complex changes to the model's structure, perhaps involving internal reorganization or sorting of data, it is necessary to emit the layoutChanged() signal to cause any attached views to be updated.
bool QAbstractItemModel::insertRows ( int row, int count, const QModelIndex & parent = QModelIndex() )
If you implement your own model, you can reimplement this function if you want to support insertions. Alternatively, you can provide your own API for altering the data. In either case, you will need to call beginInsertRows() and endInsertRows() to notify other components that the model has changed.
你也可以用自己的api来改变数据。两种情况下都要调用beginInsertRows() and endInsertRows() 来通知其他模块（notify attached views and delegates）model已经改变。
Lazy population of model data
Lazy population of model data effectively allows requests for information about the model to be deferred until it is actually needed by views.
需要时候才取。
Some models need to obtain data from remote sources, or must perform time-consuming operations to obtain information about the way the data is organized. Since views generally request as much information as possible in order to accurately display model data, it can be useful to restrict the amount of information returned to them to reduce unnecessary follow-up requests for data.
In hierarchical models where finding the number of children of a given item is an expensive operation, it is useful to ensure that the model's rowCount()implementation is only called when necessary. In such cases, the hasChildren() function can be reimplemented to provide an inexpensive way for views to check for the presence of children and, in the case of QTreeView, draw the appropriate decoration for their parent item.
Whether the reimplementation of hasChildren() returns true or false, it may not be necessary for the view to call rowCount() to find out how many children are present. For example, QTreeView does not need to know how many children there are if the parent item has not been expanded to show them.
If it is known that many items will have children, reimplementing hasChildren() to unconditionally return true is sometimes a useful approach to take. This ensures that each item can be later examined for children while making initial population of model data as fast as possible. The only disadvantage is that items without children may be displayed incorrectly in some views until the user attempts to view the non-existent child items.