1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
/****************************************************************************
**
** Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
** Contact: http://www.qt-project.org/legal
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Digia. For licensing terms and
** conditions see http://qt.digia.com/licensing. For further information
** use the contact form at http://qt.digia.com/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: http://www.gnu.org/copyleft/fdl.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\example sql/sqlwidgetmapper
\title SQL Widget Mapper Example
\brief The SQL Widget Mapper example shows how to use a map information from a
database to widgets on a form.
\image sql-widget-mapper.png
In the \l{Combo Widget Mapper Example}, we showed how to use a named
mapping between a widget mapper and a QComboBox widget with a special
purpose model to relate values in the model to a list of choices.
Again, we create a \c Window class with an almost identical user interface,
providing a combo box to allow their addresses to be classified as "Home",
"Work" or "Other". However, instead of using a separate model to hold these
address types, we use one database table to hold the example data and
another to hold the address types. In this way, we store all the
information in the same place.
\section1 Window Class Definition
The class provides a constructor, a slot to keep the buttons up to date,
and a private function to set up the model:
\snippet examples/sql/sqlwidgetmapper/window.h Window definition
In addition to the QDataWidgetMapper object and the controls used to make
up the user interface, we use a QStandardItemModel to hold our data and
a QStringListModel to hold information about the types of address that
can be applied to each person's data.
\section1 Window Class Implementation
The first act performed by the \c Window class constructor is to set up
the model used to hold the example data. Since this is a key part of the
example, we will look at this first.
The model is initialized in the window's \c{setupModel()} function. Here,
we create a SQLite database containing a "person" table with primary key,
name, address and type fields.
\snippet examples/sql/sqlwidgetmapper/window.cpp Set up the main table
On each row of the table, we insert default values for these fields,
including values for the address types that correspond to the address
types are stored in a separate table.
\image widgetmapper-sql-mapping-table.png
We create an "addresstype" table containing the identifiers used in the
"person" table and the corresponding strings:
\snippet examples/sql/sqlwidgetmapper/window.cpp Set up the address type table
The "typeid" field in the "person" table is related to the contents of
the "addresstype" table via a relation in a QSqlRelationalTableModel.
This kind of model performs all the necessary work to store the data in
a database and also allows any relations to be used as models in their
own right.
In this case, we have defined a relation for the "typeid" field in the
"person" table that relates it to the "id" field in the "addresstype"
table and which causes the contents of the "description" field to be
used wherever the "typeid" is presented to the user. (See the
QSqlRelationalTableModel::setRelation() documentation for details.)
\image widgetmapper-sql-mapping.png
The constructor of the \c Window class can be explained in three parts.
In the first part, we set up the model used to hold the data, then we set
up the widgets used for the user interface:
\snippet examples/sql/sqlwidgetmapper/window.cpp Set up widgets
We obtain a model for the combo box from the main model, based on the
relation we set up for the "typeid" field. The call to the combo box's
\l{QComboBox::}{setModelColumn()} selects the field in the field in the
model to display.
Note that this approach is similar to the one used in the
\l{Combo Widget Mapper Example} in that we set up a model for the
combo box. However, in this case, we obtain a model based on a relation
in the QSqlRelationalTableModel rather than create a separate one.
Next, we set up the widget mapper, relating each input widget to a field
in the model:
\snippet examples/sql/sqlwidgetmapper/window.cpp Set up the mapper
For the combo box, we already know the index of the field in the model
from the \c{setupModel()} function. We use a QSqlRelationalDelegate as
a proxy between the mapper and the input widgets to match up the "typeid"
values in the model with those in the combo box's model and populate the
combo box with descriptions rather than integer values.
As a result, the user is able to select an item from the combo box,
and the associated value is written back to the model.
The rest of the constructor is very similar to that of the
\l{Simple Widget Mapper Example}:
\snippet examples/sql/sqlwidgetmapper/window.cpp Set up connections and layouts
We show the implementation of the \c{updateButtons()} slot for
completeness:
\snippet examples/sql/sqlwidgetmapper/window.cpp Slot for updating the buttons
\omit
\section1 Delegate Class Definition and Implementation
The delegate we use to mediate interaction between the widget mapper and
the input widgets is a small QItemDelegate subclass:
\snippet examples/sql/sqlwidgetmapper/delegate.h Delegate class definition
This provides implementations of the two standard functions used to pass
data between editor widgets and the model (see the \l{Delegate Classes}
documentation for a more general description of these functions).
Since we only provide an empty implementation of the constructor, we
concentrate on the other two functions.
The \l{QItemDelegate::}{setEditorData()} implementation takes the data
referred to by the model index supplied and processes it according to
the presence of a \c currentIndex property in the editor widget:
\snippet examples/sql/sqlwidgetmapper/delegate.cpp setEditorData implementation
If, like QComboBox, the editor widget has this property, it is set using
the value from the model. Since we are passing around QVariant values,
the strings stored in the model are automatically converted to the integer
values needed for the \c currentIndex property.
As a result, instead of showing "0", "1" or "2" in the combo box, one of
its predefined set of items is shown. We call QItemDelegate::setEditorData()
for widgets without the \c currentIndex property.
The \l{QItemDelegate::}{setModelData()} implementation performs the reverse
process, taking the value stored in the widget's \c currentIndex property
and storing it back in the model:
\snippet examples/sql/sqlwidgetmapper/delegate.cpp setModelData implementation
\endomit
\section1 Summary and Further Reading
The use of a separate model for the combo box and a special delegate for the
widget mapper allows us to present a menu of choices to the user. Although
the choices are stored in the same database as the user's data, they are held
in a separate table. Using this approach, we can reconstructed complete records
at a later time while using database features appropriately.
If SQL models are not being used, it is still possible to use more than
one model to present choices to the user. This is covered by the
\l{Combo Widget Mapper Example}.
*/
|
