Some QML Items use Data Models to provide the data to be displayed. These items typically require a delegate component that creates an instance for each item in the model. Models may be static, or have items modified, inserted, removed or moved dynamically.
Data is provided to the delegate via named data roles which the delegate may bind to. The roles are exposed as properties of the model context property, though this property is set as a default property of the delegate so, unless there is a naming clash with a property in the delegate, the roles are usually accessed unqualified. The example below would have a clash between the color role of the model and the color property of the Rectangle. The clash is avoided by referencing the color property of the model by its full name: model.color.
ListModel {
id: myModel
ListElement { color: "red" }
ListElement { color: "green" }
}
Component {
id: myDelegate
Rectangle {
width: 20; height: 20
color: model.color
}
}
A special index role containing the index of the item in the model is also available.
Note: the index role will be set to -1 if the item is removed from the model. If you bind to the index role, be sure that the logic accounts for the possibility of index being -1, i.e. that the item is no longer valid. Usually the item will shortly be destroyed, but it is possible to delay delegate destruction in some views via a delayRemove attached property.
Models that do not have named roles will have the data provided via the modelData role. The modelData role is also provided for Models that have only one role. In this case the modelData role contains the same data as the named role.
There are a number of QML elements that operate using data models:
QML supports several types of data model, which may be provided by QML or C++ (via QDeclarativeContext::setContextProperty() or as plugin types, for example).
ListModel is a simple hierarchy of elements specified in QML. The available roles are specified by the ListElement properties.
ListModel {
id: fruitModel
ListElement {
name: "Apple"
cost: 2.45
}
ListElement {
name: "Orange"
cost: 3.25
}
ListElement {
name: "Banana"
cost: 1.95
}
}
The above model has two roles, name and cost. These can be bound to by a ListView delegate, for example:
Component {
id: fruitDelegate
Row {
Text { text: "Fruit: " + name }
Text { text: "Cost: $" + cost }
}
}
ListView {
model: fruitModel
delegate: fruitDelegate
}
It is also possible to manipulate the ListModel directly via JavaScript. In this case, the first item inserted will determine the roles available to any views using the model. For example, if an empty ListModel is created and populated via JavaScript the roles provided by the first insertion are the only roles that will be shown in the view:
Item {
ListModel {
id: fruitModel
}
MouseArea {
anchors.fill: parent
onClicked: fruitModel.append({"cost": 5.95, "name":"Pizza"})
}
}
When the MouseArea is clicked fruitModel will have two roles, "cost" and "name". Even if subsequent roles are added, only the first two will be handled by views using the model.
XmlListModel allows construction of a model from an XML data source. The roles are specified via the XmlRole element.
The following model has three roles, title, link and description:
XmlListModel {
id: feedModel
source: "http://rss.news.yahoo.com/rss/oceania"
query: "/rss/channel/item"
XmlRole { name: "title"; query: "title/string()" }
XmlRole { name: "link"; query: "link/string()" }
XmlRole { name: "description"; query: "description/string()" }
}
VisualItemModel allows QML items to be provided as a model. This model contains both the data and delegate (its child items). This model does not provide any roles.
VisualItemModel {
id: itemModel
Rectangle { height: 30; width: 80; color: "red" }
Rectangle { height: 30; width: 80; color: "green" }
Rectangle { height: 30; width: 80; color: "blue" }
}
ListView {
anchors.fill: parent
model: itemModel
}
Note that in the above example there is no delegate required. The items of the model itself provide the visual elements that will be positioned by the view.
Models defined in C++ can be made available to QML either from a C++ application or from a QML C++ plugin.
A model can be defined by subclassing QAbstractItemModel.
QAbstractItemModel provides the roles set via the QAbstractItemModel::setRoleNames() method. The default role names set by Qt are:
| Qt Role | QML Role Name |
|---|---|
Qt::DisplayRole | display |
Qt::DecorationRole | decoration |
The model could be made available to QML either directly:
QDeclarativeContext *ctxt = view.rootContext();
MyModel *model = new MyModel; // subclass of QAbstractItemModel
ctxt->setContextProperty("myModel", model);
or by registering the subclass as a new QML type in a QML C++ plugin.
QAbstractItemModel presents a heirachy of tables, but views currently provided by QML can only display list data. In order to display child lists of a heirachical model the VisualDataModel element provides several properties and functions for use with models of type QAbstractItemModel:
A model may be a simple QStringList, which provides the contents of the list via the modelData role:
// main.cpp
QStringList dataList;
dataList.append("Fred");
dataList.append("Ginger");
dataList.append("Skipper");
QDeclarativeContext *ctxt = view.rootContext();
ctxt->setContextProperty("myModel", QVariant::fromValue(dataList));
| // main.qml
ListView {
width: 100
height: 100
anchors.fill: parent
model: myModel
delegate: Component {
Rectangle {
height: 25
Text { text: modelData }
}
}
}
|
Note: There is no way for the view to know that the contents of a QStringList have changed. If the QStringList is changed, it will be necessary to reset the model by calling QDeclarativeContext::setContextProperty() again.
QList<QObject*> provides the properties of the objects in the list as roles.
class DataObject : public QObject
{
Q_OBJECT
Q_PROPERTY(QString name READ name WRITE setName)
Q_PROPERTY(QString color READ color WRITE setColor)
...
};
QList<QObject*> dataList;
dataList.append(new DataObject("Item 1", "red"));
dataList.append(new DataObject("Item 2", "green"));
dataList.append(new DataObject("Item 3", "blue"));
dataList.append(new DataObject("Item 4", "yellow"));
QDeclarativeContext *ctxt = view.rootContext();
ctxt->setContextProperty("myModel", QVariant::fromValue(dataList));
The QObject* is available as the modelData property. As a convenience, the properties of the object are also made available directly in the delegate's context:
ListView {
width: 100
height: 100
anchors.fill: parent
model: myModel
delegate: Component {
Rectangle {
height: 25
width: 100
color: model.modelData.color
Text { text: name }
}
}
}
Note the use of the fully qualified access to the color property. The properties of the object are not replicated in the model object, since they are easily available via the modelData object.
Note: There is no way for the view to know that the contents of a QList have changed. If the QList is changed, it will be necessary to reset the model by calling QDeclarativeContext::setContextProperty() again.
An Integer specifies a model containing the integer number of elements. There are no data roles.
The following example creates a ListView with five elements:
Item {
width: 200
height: 250
Component {
id: itemDelegate
Text { text: "I am item number: " + index }
}
ListView {
anchors.fill: parent
model: 5
delegate: itemDelegate
}
}
An Object Instance specifies a model with a single Object element. The properties of the object are provided as roles.
The example below creates a list with one item, showing the color of the myText text. Note the use of the fully qualified model.color property to avoid clashing with color property of the Text element in the delegate.
Rectangle {
Text {
id: myText
text: "Hello"
color: "#dd44ee"
}
Component {
id: myDelegate
Text {
text: model.color
}
}
ListView {
anchors.fill: parent
anchors.topMargin: 30
model: myText
delegate: myDelegate
}
}