在PyQt和Qt中,Model/View架构是图形界面开发时用于管理数据和界面展现方式的关系。由该体系架构引入的功能分离使得开发人员能够更灵活地定制展现数据项的呈现方式,并提供标准模型接口支持广泛的数据源与预定义好的项视图(item views)一起使用。
模型-视图-控制器(Model-View-Controller,简称MVC)是一种源于Smalltalk在构建用户界面时 广泛使用的设计模式。在《Design Patterns》一书中,Gamma等人这样描述到:“MVC由三种对象组成。模型Model是应用程序对象,视图View是其屏幕表示,控制器Controller定义用户界面对用户输入的反应方式。在MVC之前,用户界面设计倾向于将这些对象组合在一起。MVC将它们解耦以增加灵活性和重用性。”
如果将MVC架构中的视图和控制器对象组合在一起,结果就是Model/View体系结构。这还是将数据的存储方式与展现给用户的方式分开,但是基于相同的原则提供了一个更简单的框架。这种分离使得可以在几个不同的视图中显示相同的数据,并实现新类型的视图,而无需更改底层数据结构。
为了允许灵活地处理用户输入,在PyQt和Qt中引入了代理Delegate的概念,代理允许自定义数据项的呈现和编辑方式。不过老猿不准备就代理的概念展开进行介绍。
一般情况下Model/View可以分为上述三组:模型Models、视图Views和代理delegates。这些组件中的每一个都是由抽象类定义的,这些抽象类提供公共接口,在某些情况下还提供特性的默认实现。抽象类应该子类化,通过子类以便提供其他组件所需要的全部功能,同时特殊情况下这也可以针对特定场景编写专门的组件。
模型、视图和代理使用信号和插槽相互通信:
所有项模型(item models )类都是从基类QAbstractItemModel 类及其子类派生的,QAbstractItemModel 类定义了一个供视图views 和代理delegates 访问数据的接口。数据本身不必存储在模型中,它可以保存在由单独的类、文件、数据库或其他应用程序组件提供的数据结构或存储库中。
QAbstractItemModel 提供了一个数据接口,该接口足够灵活地处理以列表、表和树的形式展现数据的视图。下图是三种模型对应数据层级示意:
然而,当为列表和类似表的数据结构实现新模型时,QAbstractListModel和QAbstractTableModel类是更好的起点,因为它们提供了公共函数的适当默认实现。这些类中的每一个都可以被子类化,以提供支持特殊类型列表或表的模型。
PyQt和Qt提供了一些现成的模型,可用于处理数据项:
如果这些标准模型不满足应用的需求,可以将QAbstractItemModel 、QAbstractListModel或QAbstractTableModel子类化,以创建自定义模型。
视图负责数据的展现,PyQt和Qt为不同类型的视图提供了完整的实现类:
这些类中的每一个都基于QAbstractItemView抽象基类,尽管这些类已实现基类的所有 抽象方法可以直接使用,但它们也可以被子类化以提供自定义视图使用。
QAbstractItemDelegate 是Model/View架构中代理的抽象基类。代理为视图中的项提供展现和编辑功能。默认的代理实现由QStyledItemDelegate提供,PyQt和Qt中预定义好的标准视图将其用作默认代理。QStyledItemDelegate使用当前样式来绘制视图中的项。Qt建议在实现自定义代理或使用Qt样式表时使用QStyledItemDelegate作为基类。
对于代理,老猿在PyQt相关内容中不进行展开介绍。
PyQt和Qt提供的两个标准模型是QStandardItemModel和QFileSystemModel。QStandardItemModel是一个多用途模型,可用于表示列表list、表table和树tree类型视图所需的各种不同数据结构,模型可以保存数据项。QFileSystemModel是一个维护文件目录内容信息的模型,它本身不包含任何数据项,而只是表示本地文件系统上的文件和目录。
QFileSystemModel 提供了一个随时可用的模型来进行实验,并且可以很容易地配置为使用现有的数据。使用此模型,我们可以演示如何设置用于现成视图的模型,并探索如何使用模型索引(model indexes)操作数据。 QListView 和 QTreeView这两个视图是最适合使用QFileSystemModel的视图。
为了确保数据的展现与访问方式保持分离,引入了模型索引的概念。通过模型可以获得的每一条数据都由模型索引表示。视图和代理使用模型索引来请求要显示的数据项。
因此,模型只需要知道如何获取数据,而模型管理的数据类型可以相当普遍。模型索引包含指向创建它们的模型对象,这可以防止在使用多个模型时出现混淆。
Qt中Model/View中的Model Index是一个类,该类用于定位Model/View中数据模型中的数据。
Model Index对应类为QModelIndex,用于在项视图( item views)、代理(delegates)和选择模型( selection models)使用来定位Model中的数据项。
模型索引引用模型中的数据项,包含一个指向创建模型索引的Model的指针,这样可以避免使用多个Model时引起混淆,模型索引包含有定位数据项在模型中的位置所需的所有信息,包括索引位置给定的行和列位置,并且可能还有父索引,这些通过使用row()、column()和parent()来获取。模型中的每个顶级项目都用一个没有父索引的模型索引来表示——在这种情况下,parent() 将返回一个无效的模型索引,相当于一个用QModelIndex()无参数形式构造的索引。
为了获取相应数据项的模型索引,可以调用QAbstractItemModel.index() ,调用时必须指定Model的三个属性:行数,列数,父项的模型索引。特殊情况下,引用模型中的顶级项时,使用QModelIndex()作为父索引。
indexA = self.model.index(0, 0, QtCore.QModelIndex())
indexB = self.model.index(1, 1, QtCore.QModelIndex())
indexC = self.model.index(2, 1, QtCore.QModelIndex())
indexA = self.model.index(0, 0, QtCore.QModelIndex())
indexC = self.model.index(2, 1, QtCore.QModelIndex())
indexB = self.model.index(1, 0, indexA)
QModelIndex对象由模型使用QAbstractItemModel.createIndex() 函数创建。可以使用QModelIndex构造函数构造无效的模型索引。当引用模型中的顶级项时,无效索引通常用作父索引。
model()函数返回索引引用的Model(类型为QAbstractItemModel),child()函数用于访问给定行和列对应索引下保存的子项。sibling()函数用于在模型中遍历与索引相同级别的数据项。
注意:模型索引为数据项提供了临时参照,通过它可以用来提取或修改Model中的数据。模型索引在获得后应该立即使用,由于Model经常会重新组织内部的结构,使得模型索引失效,因此不应保存模型索引。如果需要一个对数据项的长期参照,必须创建一个永久的模型索引。这样会为不断更新的Model信息提供一个参照。临时模型索引由QModelIndex类提供,而永久模型索引则由QPersistentModelIndex类提供。
在PyQt中,模型可以针对不同的组件(或者组件的不同部分,比如存储数据、界面展示数据、按钮的提示等)提供不同的数据。例如,Qt.DisplayRole用于视图的文本显示。通常来说,模型中的数据项包含一系列不同的数据角色,数据角色定义在 Qt.ItemDataRole 枚举中,包括下列枚举值:
Qt.DisplayRole:文本表格中要渲染显示的数据,当存储的内部字典值要显示为可理解的文字含义数据时对应数据与实际存储数据会不一致
Qt.EditRole:编辑器中正在编辑的数据,老猿认为这也应该是实际存储的数据
Qt.ToolTipRole:数据项的工具提示的显示数据
Qt.WhatsThisRole:项为"What’s This?"模式显示的数据
Qt.DecorationRole:数据被渲染为图标等装饰(数据为QColor/ QIcon/ QPixmap类型)
Qt.StatusTipRole:数据显示在状态栏中(数据为QString类型)
Qt.SizeHintRole:数据项的大小提示,将会应用到视图(数据为QString类型)
Qt.CheckStateRole:数据项前面的checkbox选择状态,当数据项构建时使用了setCheckable(True)时会发生作用
Qt.TextAlignmentRole:数据项对齐方式,当设置了数据项的对齐格式时有效
几个常量的值:
Qt.DisplayRole=0
Qt.DecorationRole=1
Qt.EditRole=2
Qt.ToolTipRole=3
Qt.StatusTipRole=4
Qt.WhatsThisRole=5
Qt.TextAlignmentRole=7
Qt.CheckStateRole=10
Qt.SizeHintRole=13
下图是几种常用数据角色的示意图:
通过为每一个角色提供恰当的数据,模型可以告诉视图和委托如何向用户显示内容。不同类型的视图可以选择忽略自己不需要的数据,也可以添加所需要的额外数据。
在Model/View体系架构中,有两种方法可以进行排序;选择哪种方法取决于底层模型。
在Model/View框架中,单个模型提供的数据项可以由任意数量的视图共享,并且每个视图可能以完全不同的方式表示相同的信息。自定义视图和代理是为同一数据提供完全不同展示结果的有效方法。但应用程序通常需要为相同数据的已处理版本提供常规视图,例如为列表数据提供不同排序的展现视图。
尽管将排序和筛选操作作为视图的内部方法来执行看起来可行,但是排序和筛选操作代价高,如果存在多个视图展示相同的数据时,每个视图数据排序按不同方式排序,如果每个视图实现类似的方法,这种操作代价高昂。
另一种方法就是在模型本身对数据进行排序,这导致每个视图都必须显示根据最近的排序或刷选操作处理后的数据项,同样代价高。
为了解决这个问题,Model/View框架使用代理模型来管理在各个模型和视图之间交互的信息。代理模型是一些组件,从视图的角度来看,它们的行为类似于普通Model,并代表该视图访问源模型中的数据。Model/View框架使用的信号和槽机制确保无论在其自身和源模型之间放置了多少代理模型,每个视图都会得到适当的更新。
老猿理解代理模型就是提供在其他的model和view之间排序和过滤数据的支持功能使用的的,在代理模型中可以对项进行排序和筛选,这种方法允许一个model采用和其视图功能匹配的要求重新组织,但不需要在数据和源模型上做任何处理,也不需要复制内存中的数据,可以有效提高效率。
代理模型可以插入到现有模型和任意数量的视图之间。PyQt和Qt提供了一个标准的代理模型QSortFilterProxyModel,它通常是直接实例化和使用的,但也可以从其派生子类来提供自定义的筛选和排序行为。
QSortFilterProxyModel类可以按以下方式使用:
语法:proxyModel = QSortFilterProxyModel((QObject parent)
语法:代理模型.setSourceModel(数据源模型)
其中代理模型就是第一步定义的模型,数据源模型即前面第三部分介绍的Model,为真正访问数据的模型。
语法:视图.setModel(proxyModel )
从以上语法看到,代理模型本身对外是个Model,但自身的数据源也是个Model。
由于代理模型继承自QAbstractItemModel,因此它们可以连接到任何类型的视图,并且可以在视图之间共享。它们还可用于从其他代理模型获得信息,类似代理模型到数据Model之间象管道一样排列使用。
QSortFilterProxyModel类被设计为实例化并直接在应用程序中使用,也可以通过特殊派生的子类实现所需的比较操作,从而创建更专门的代理模型。
QSortFilterProxyModel的具体过滤和刷选的方法请参考类相关的方法介绍,在此不进行展开说明。
为了使依赖于PyQt或Qt基于项的视图和表类的应用程序受益,从标准视图类派生了许多便利类,这些便利类不建议使用于派生子类。
这些类包括QListWidget、QTreeWidget和QTableWidget。这些类比视图类更不灵活,不能与任意模型一起使用。PyQt或Qt建议使用Model/View方法处理项视图(item views)中的数据,除非强烈需要一组基于项的类(item-based)。
如果希望在仍使用基于项的接口类时利用Model/View方法提供的功能,请考虑使用视图类,例如使用QStandardItemModel作为模型Model的QListView、QTableView和QTreeView视图类。
本节部分还缺一个与Model/View架构相关的类的总体介绍,在此请大家参考《PyQt学习随笔:Qt中Model/View相关的主要类及继承关系》。
本节主要介绍了:
Model/View架构中模型、视图、模型索引、代理等相关的概念
模型索引(Model indexes )以独立于任何底层数据结构的方式提供有关模型中数据项的位置的信息给代理和视图使用,模型索引是在其他组件(如视图和代理)的请求下由模型构造的
项的构成要素包括行和列编号以及其父项的模型索引
角色用于区分与项关联的代表同一数据中的要素但展现不同用途的数据
本文主要介绍Model/View开发架构的相关概念,相关内容主要从Qt官网文章翻译而成,结合老猿的理解做了一些补充。没有全部写新的内容是因为概念引用原文比较成体系。
本节应该是Model/View相关章节的首节来介绍,但老猿也是边学习边摸索,可不能简单将Qt官网文档简单翻译,因此才在此部分进行介绍。
另外老猿关于PyQt的付费专栏《使用PyQt开发图形界面Python应用》只需要9.9元,该部分与第十五章的内容基本对应,但同样内容在付费专栏上总体来说更详细、案例更多。本节内容在付费专栏的《第十四章、Model/View开发:Model/View架构程序设计模式》。如果有兴趣也愿意支持老猿的读者,欢迎购买付费专栏。