diff options
Diffstat (limited to 'doc/src/examples/sqlwidgetmapper.qdoc')
-rw-r--r-- | doc/src/examples/sqlwidgetmapper.qdoc | 185 |
1 files changed, 0 insertions, 185 deletions
diff --git a/doc/src/examples/sqlwidgetmapper.qdoc b/doc/src/examples/sqlwidgetmapper.qdoc deleted file mode 100644 index b9ea28849e..0000000000 --- a/doc/src/examples/sqlwidgetmapper.qdoc +++ /dev/null @@ -1,185 +0,0 @@ -/**************************************************************************** -** -** Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies). -** Contact: http://www.qt-project.org/ -** -** This file is part of the documentation of the Qt Toolkit. -** -** $QT_BEGIN_LICENSE:FDL$ -** GNU Free Documentation License -** 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. -** -** Other Usage -** Alternatively, this file may be used in accordance with the terms -** and conditions contained in a signed written agreement between you -** and Nokia. -** -** -** -** -** -** $QT_END_LICENSE$ -** -****************************************************************************/ - -/*! - \example sql/sqlwidgetmapper - \title SQL Widget Mapper Example - - 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}. -*/ |