NCV55-新查询模板技术红皮书v1.1

图4 新查询模板排序页签

第一章 设计介绍

1.1 模型介绍

查询模板最终形成的Where条件总是由若干个相对独立的小条件通过and和or操作符组合合成的。比如:部门=’生产部’ and (人员编码=’P0001’ or 人员编码=’P0003’)。在新查询模板中，这样每个独立的小条件由一个IFilter接口来描述。IFilter又分成三个组成部分，元信息(IFilterMeta)，操作符(IOperator)，和字段取值(IFieldValue)。

IFilterIFilterMetaIOperatorIFieldValueIFieldValueElement 图2.1 Filter类结构图

FilterMeta（IFilterMeta的在查询模板中的默认实现）描述了条件字段的元信息，相当于老查询模板的QueryConditionVO。FilterMeta目前实际就是通过把QueryConditionVO进行转换操作后生成的，或从单据元数据生成。IOperator接口是对操作符的抽象。IFileldValue接口是对字段取值的抽象，它实际只有一个方法，即返回一个IFieldValueElement的集合。IFieldValueElement是对一个“原子”值的抽象，实际可能是描述了一个整数，或者是一个枚举值，或者是参照返回值。

整个的Where条件就可以看成由and,or操作符以及IFilter形成的一棵树，在新查询模板中以QueryTree来描述。前面举的例子，表示成树的形式就如下图所示。

And 部门=’生产部’ Or 人员编码=’P0001’ 人员编码=’P0002’ 图2.2 查询条件树

不论是高级视图还是常规视图，其内部都是用QueryTree来组织单个的IFilter的。QueryTree及相关类结构图如下图所示：

QueryTreeQueryTreeNodeIlogicalOperatorOperatorNodeFilterNodeIFilterAndOperatorOrOperator图2.3 QueryTree相关类结构图

1.2 默认编辑器及扩展机制

基于前面的模型，查询模板从功能上就可以理解为一个是能对QueryTree和IFilter进行编辑的编辑器。

对QueryTree的编辑实际就是把IFilter看成最小的单元，提供一定的方法，让用户修改IFilter之间的与或关系。对于常规视图来说，用户不用关心，实际也不能修改，IFilter之间的与或关系。常规视图上的IFitler都是“与(AND)”的关系，用户不能修改，只能增加或删除IFilter。对于高级视图，用户可以则可以任意调整IFilter之间的与或关系，从而构造出复杂的查询条件。

新查询模板对QueryTree的编辑没有设计扩展机制，因为对与或关系的编辑没有太多的特殊性需求，常规视图和高级视图已经能完全满足简单条件和复杂的条件的编辑了。但是对于IFilter的编辑，往往是和具体的业务相关的，默认的编辑方式不一定能满足业务的要求。因此新查询模板针对这个问题重点做了设计，支持在不同层次上对IFilter编辑进行扩展。 对IFilter进行编辑的编辑器被抽象为接口IFilterEditor，当查询模板需要一个IFilter的编辑器，即一个IFilterEditor实例时，会调用FilterEditorManager创建出一个。默认的情况下查询模板创建出来的是DefaultFilterEditor，如图2.4所示。如果DefaultFilterEditor不能满足业务的需要，则可以按需定制符合要求的编辑器，并注册到FilterEditorManager中，即可实现对DefaultFilterEditor的替换。图2.5展示了一个定制的FilterEditor，对于“经济类型”这样的枚举型字段，采用图示的编辑器可能更方便。

2.4 默认编辑器

2.5自定义编辑器

图2.4中被红色线框框住的部分即是DefaultFilterEditor，它由三部分组成：左边是显示FilterMeta的Label控件，中间是供选择操作符的下拉框控件，右边被绿色线框框住的部分是对IFieldValue进行编辑的编辑器，抽象为IFieldValueEditor，默认情况下创建出来的是DefaultFieldValueEditor，同DefaultFilterEditor一样，通过FieldValueEditorManager注册定制的编辑器，DefaultFieldValueEditor也是可以被替换的。

如前文所述，IFieldValue是对IFieldValueElement包装，而DefaultFieldValueEditor实际上是对IFieldValueElementEditor的包装。DefaultFieldValueEditor包含了两个IFieldValueElementEditor的实例，根据用户所选择的操作符的不同会有不同的界面展现。图2.4中选择的是“介于”操作符，它是一个接受2个参数的操作符，因此DefaultFieldValueEditor把两个IFieldValueElementEditor都显示出来了。如果是其他情况，即操作符是接受0个，1个，任意多个参数时，DefaultFieldValueEditor总是显示一个IFieldValueElementEditor，但会根据操作符接受参数的个数，设置IFieldValueElementEditor是否允许多选。上面所描述的DefaultFieldValueEditor的行为如果符合业务的需要，那么你可以坦然接受它，反之则是定制你自己的IFieldValueEditor的时候了。

在没替换DefaultFieldValueEditor的情况下，用户在为某个查询条件选定一个部门，或者一个公司，或者输入一个订单货品的数量，实际都是通过IFieldValueElementEditor进行的，而后者是通过IFieldValueElementEditorManager创建出来的，默认的情况下它又把这个任务委托给了DefaultFieldValueElementEditorFactory这个工厂类。这个工厂类根据注册在pub_query_condition的信息，主要是字段的数据类型等信息，生产出合适的IFieldValueElementEditor实例。同样地，这个过程也是可以根据需要扩展的，支持注册定制的IFieldValueElementEditor。

综上所述，新查询模板对IFilter的编辑，分别在IFilterEditor，IFieldValueEditor，IFieldValueElementEditor三个层次上提供了扩展机制，在实际使用时可以根据情况具体选择扩展方式。图2.6是相关的类图，从中可以看到，这三个层次的扩展机制是完全相同的。都是由一个IXXEditor接口来表示编辑器，然后有一个IXXEditorFactory的工厂来负责创建编辑器，一个XXEditorManager来管理工厂。注册一个定制的编辑器，概况来讲可以分成三个步骤，1.提供一个实现了IXXEditor接口的自定义编辑器2.提供一个相应的工厂类，负责生产该自定义编辑器3.把该工厂类注册到XXEditorManager中。

关于如何注册，请参看开发说明有关章节。