第二章 视图

我们在第二部分介绍了大多户常用视图的类型及其特性,本章介绍的是视图世界的最后一块拼图,它的内部原理。

视图的继承机制

首先,我们先来看一下多个视图继承的内部机制。我们在第二部分没有提到的一个部分是视图继承是有两种模式的:主继承扩展继承。继承模式使用的字段是mode, 该字段仅在inherit_id有值时有效。

该机制的可以简述为一下描述:

多视图继承时以每一个主视图下的拓展视图的先序遍历和深度优先的原则进行

我们这里以官方代码中的示例来举例:

# Example:                  hierarchy = {
#                               1: [2, 3],  # primary view
#             1*                2: [4, 5],
#            / \                3: [],
#           2   3               4: [6],     # primary view
#          / \                  5: [7, 8],
#         4*  5                 6: [],
#        /   / \                7: [],
#       6   7   8               8: [],
#                           }

上图中,1和4是主视图,其余为拓展视图。

odoo在进行视图渲染的时候,会以1->2->5->7->8->3->4->6的顺序进行解析和叠加渲染。

实际上odoo在处理这个遍历逻辑的时候使用了双端队列的一个数据结构,对于主视图,让它从队尾入列,扩展视图则从队首入列。这样我们就能将上面的视图转换成下面的数组:

1: [2,3]            # 第一步解析主视图1
2: [5,3,4]          # 第二步视图2出列,解析成4、5, 4从右侧入列,5从左侧入列
3: [7,8,3,4]        # 第三步视图5出列,解析成7、8,都从左侧入列
4: [8,3,4]          # 第四步视图7出列,渲染
5: [3,4]            # 第五步视图8出列,渲染
6: [4]              # 第六步视图3出列,渲染
7: [6]              # 第七步视图4出列,解析成视图6
8: []               # 第八步视图6出列,完成渲染

这就是我们的视图在叠加解析时的内部逻辑。

results matching ""

    No results matching ""