1 | /****************************************************************************
|
---|
2 | **
|
---|
3 | ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
|
---|
4 | ** Contact: Qt Software Information ([email protected])
|
---|
5 | **
|
---|
6 | ** This file is part of the documentation of the Qt Toolkit.
|
---|
7 | **
|
---|
8 | ** $QT_BEGIN_LICENSE:LGPL$
|
---|
9 | ** Commercial Usage
|
---|
10 | ** Licensees holding valid Qt Commercial licenses may use this file in
|
---|
11 | ** accordance with the Qt Commercial License Agreement provided with the
|
---|
12 | ** Software or, alternatively, in accordance with the terms contained in
|
---|
13 | ** a written agreement between you and Nokia.
|
---|
14 | **
|
---|
15 | ** GNU Lesser General Public License Usage
|
---|
16 | ** Alternatively, this file may be used under the terms of the GNU Lesser
|
---|
17 | ** General Public License version 2.1 as published by the Free Software
|
---|
18 | ** Foundation and appearing in the file LICENSE.LGPL included in the
|
---|
19 | ** packaging of this file. Please review the following information to
|
---|
20 | ** ensure the GNU Lesser General Public License version 2.1 requirements
|
---|
21 | ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
|
---|
22 | **
|
---|
23 | ** In addition, as a special exception, Nokia gives you certain
|
---|
24 | ** additional rights. These rights are described in the Nokia Qt LGPL
|
---|
25 | ** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
|
---|
26 | ** package.
|
---|
27 | **
|
---|
28 | ** GNU General Public License Usage
|
---|
29 | ** Alternatively, this file may be used under the terms of the GNU
|
---|
30 | ** General Public License version 3.0 as published by the Free Software
|
---|
31 | ** Foundation and appearing in the file LICENSE.GPL included in the
|
---|
32 | ** packaging of this file. Please review the following information to
|
---|
33 | ** ensure the GNU General Public License version 3.0 requirements will be
|
---|
34 | ** met: http://www.gnu.org/copyleft/gpl.html.
|
---|
35 | **
|
---|
36 | ** If you are unsure which license is appropriate for your use, please
|
---|
37 | ** contact the sales department at [email protected].
|
---|
38 | ** $QT_END_LICENSE$
|
---|
39 | **
|
---|
40 | ****************************************************************************/
|
---|
41 |
|
---|
42 | /*!
|
---|
43 | \example sql/sqlwidgetmapper
|
---|
44 | \title SQL Widget Mapper Example
|
---|
45 |
|
---|
46 | The SQL Widget Mapper example shows how to use a map information from a
|
---|
47 | database to widgets on a form.
|
---|
48 |
|
---|
49 | \image sql-widget-mapper.png
|
---|
50 |
|
---|
51 | In the \l{Combo Widget Mapper Example}, we showed how to use a named
|
---|
52 | mapping between a widget mapper and a QComboBox widget with a special
|
---|
53 | purpose model to relate values in the model to a list of choices.
|
---|
54 |
|
---|
55 | Again, we create a \c Window class with an almost identical user interface,
|
---|
56 | providing a combo box to allow their addresses to be classified as "Home",
|
---|
57 | "Work" or "Other". However, instead of using a separate model to hold these
|
---|
58 | address types, we use one database table to hold the example data and
|
---|
59 | another to hold the address types. In this way, we store all the
|
---|
60 | information in the same place.
|
---|
61 |
|
---|
62 | \section1 Window Class Definition
|
---|
63 |
|
---|
64 | The class provides a constructor, a slot to keep the buttons up to date,
|
---|
65 | and a private function to set up the model:
|
---|
66 |
|
---|
67 | \snippet examples/sql/sqlwidgetmapper/window.h Window definition
|
---|
68 |
|
---|
69 | In addition to the QDataWidgetMapper object and the controls used to make
|
---|
70 | up the user interface, we use a QStandardItemModel to hold our data and
|
---|
71 | a QStringListModel to hold information about the types of address that
|
---|
72 | can be applied to each person's data.
|
---|
73 |
|
---|
74 | \section1 Window Class Implementation
|
---|
75 |
|
---|
76 | The first act performed by the \c Window class constructor is to set up
|
---|
77 | the model used to hold the example data. Since this is a key part of the
|
---|
78 | example, we will look at this first.
|
---|
79 |
|
---|
80 | The model is initialized in the window's \c{setupModel()} function. Here,
|
---|
81 | we create a SQLite database containing a "person" table with primary key,
|
---|
82 | name, address and type fields.
|
---|
83 |
|
---|
84 | \snippet examples/sql/sqlwidgetmapper/window.cpp Set up the main table
|
---|
85 |
|
---|
86 | On each row of the table, we insert default values for these fields,
|
---|
87 | including values for the address types that correspond to the address
|
---|
88 | types are stored in a separate table.
|
---|
89 |
|
---|
90 | \image widgetmapper-sql-mapping-table.png
|
---|
91 |
|
---|
92 | We create an "addresstype" table containing the identifiers used in the
|
---|
93 | "person" table and the corresponding strings:
|
---|
94 |
|
---|
95 | \snippet examples/sql/sqlwidgetmapper/window.cpp Set up the address type table
|
---|
96 |
|
---|
97 | The "typeid" field in the "person" table is related to the contents of
|
---|
98 | the "addresstype" table via a relation in a QSqlRelationalTableModel.
|
---|
99 | This kind of model performs all the necessary work to store the data in
|
---|
100 | a database and also allows any relations to be used as models in their
|
---|
101 | own right.
|
---|
102 |
|
---|
103 | In this case, we have defined a relation for the "typeid" field in the
|
---|
104 | "person" table that relates it to the "id" field in the "addresstype"
|
---|
105 | table and which causes the contents of the "description" field to be
|
---|
106 | used wherever the "typeid" is presented to the user. (See the
|
---|
107 | QSqlRelationalTableModel::setRelation() documentation for details.)
|
---|
108 |
|
---|
109 | \image widgetmapper-sql-mapping.png
|
---|
110 |
|
---|
111 | The constructor of the \c Window class can be explained in three parts.
|
---|
112 | In the first part, we set up the model used to hold the data, then we set
|
---|
113 | up the widgets used for the user interface:
|
---|
114 |
|
---|
115 | \snippet examples/sql/sqlwidgetmapper/window.cpp Set up widgets
|
---|
116 |
|
---|
117 | We obtain a model for the combo box from the main model, based on the
|
---|
118 | relation we set up for the "typeid" field. The call to the combo box's
|
---|
119 | \l{QComboBox::}{setModelColumn()} selects the field in the field in the
|
---|
120 | model to display.
|
---|
121 |
|
---|
122 | Note that this approach is similar to the one used in the
|
---|
123 | \l{Combo Widget Mapper Example} in that we set up a model for the
|
---|
124 | combo box. However, in this case, we obtain a model based on a relation
|
---|
125 | in the QSqlRelationalTableModel rather than create a separate one.
|
---|
126 |
|
---|
127 | Next, we set up the widget mapper, relating each input widget to a field
|
---|
128 | in the model:
|
---|
129 |
|
---|
130 | \snippet examples/sql/sqlwidgetmapper/window.cpp Set up the mapper
|
---|
131 |
|
---|
132 | For the combo box, we already know the index of the field in the model
|
---|
133 | from the \c{setupModel()} function. We use a QSqlRelationalDelegate as
|
---|
|
---|