高级查询功能是针对所有流程及表单数据的查询入口，作为工作流报表的暂时性替代功能，对于领导和相关流程的业务单位来说十分重要。高级查询功能提供了包括了流程名称、发起人、发起人所属部门等的基本条件查询以及可用作查询条件（是否可用作查询条件在列定义中设置，选中某个表单后，可供选择的列自动展示，并且根据列定义中的数据格式提供不同的查询方式，比如模糊匹配、比如日期的区间查询等）的高级条件查询，通过组合查询条件得到想要的查询结果。

由于高级查询一直存在分布的问题，究其原因主要是前端的展示与后台的分布难以协同，oaGrid或者原生的kendoGrid均无法展现动态列（这个问题网上确实没有例子，有gridView可以实现动态列的范例）。高级查询先后经历无分页（用<table>标签拼接）、伪前端分页等一系列演化。

　　高级查询的权限控制等在前面的博文中有介绍，本文主要介绍针对高级查询结果的前后端协同的分页实现。下面介绍一下目前的实现逻辑以及整个优化的历程。该功能的需求最初由我定义，形成需求后下发给工程师R具体实现，关于条件组合、sql拼接我们暂时不介绍，当时作为雏形的结果展示是一种一次查询出所有结果，然后采用<table>标签动态接拼展示动态的查询结果。下面是最初的实现：

　　以上的js比较简单，第一、从高级查询条件中获得表单信息；第二、循环遍历一行一行地写进<table>。

　　由于开发这一版本的时候正是OA一期上线的关键时期，R对我说实现分布的功能对于kendoGrid是不可能的，而当时我们所有的表格的展示用的都是基于kendoGrid的oaGrid，熟悉kendoGrid和js的主管Z也说kendoGrid实现动态列的分布是不行的。当时刚刚担任主管的我本着“评价个冰箱，自己一定也得会制冷”、“要求别人做到的，自己先做到”，而当时的我刚从上家公司C/S开发上转过来不久，对BS结构以及js等前端的开发技术并不了解，所以只有暂时接受这种根本没有分页的方案。

　　但这个一直是我关注的心结之一，不久我将该任务分配给了高中毕业，但热衷技术、态度端正、经总监推荐、总经理还是副总裁特批进来的L，结果仍然是以grid无法实现动态列且前后端分页而不了了之。

　　再接下来，新入职的G，熟悉js但对grid并不了解。我当时按照固有的思路，即实现前后端分页是不行的。在当时的OA的原项目经理、后来转做技术总监的徐总指导下，在这个固有的思路指引下，开发了基于原生kendoGrid的页面的前端分页。该实现并不是真正的分页查询，只是将所有数据查询后，在前端的分页展示。但这个方案以及其部分实现确实为我后来解决oaGrid的分页提供了一种很好的思路。我们看一下这个阶段的实现：

　　这一版本的相校初始版本一是实现了用户直接感观的分页，二是表格样式比较美观。

　　这一版本的设计中实际已经组装出了oaGrid所需的columns，其设计思路剑走偏锋，对columns的组装从查询的高级条件中直接获取，比我之前设想的从后台组装columns更简单、易行且更符合需求（从后台组装实际无法判断哪些字段是用户期望展示的，虽然可以将状态\id等写死在判断代码中）。

　　通过第二版本引出了关于前台应用oaGrid分页的思路，前端的代码如下，这一版本相当简单，保持了代码风格的统一，即查询结果使用oaGrid展示及分页：

　　参考一般模块的grid分页的逻辑，其grid的列是固定的，分页逻辑的采用了com.gaochao.platform.orm.mybatis.PagingIntercept，对所有的query方法进行分页，如传进的参数有start和limit，就将start和limit设置进来，如果没有，则默认使用limit=2147483647，offset=0，为普通查询语句添加分页逻辑。在oaGrid.js中有page\skip用来传递页码和页数，然后进行查询。

　　经过查看gc.oaTools.js中的oaGird实现，在第L608

}并结合网上的关于dendoGrid的范例model的格式即为我们使用一般模块使用oaGrid时前端传入的columns数组，再反观data和total即是我们com.gaochao.platform.entity.PageResult中的两个属性，由此我们得到一种方案，即columns不由前端传入而改为重写PageResult加入dataModel，并在后端实现dataModel的拼接（拼接会查询数据库，可能影响效率）。

　　第二种方案：很多关于mybatis的分页方案是采用了所谓的Interceptor，对某些数据库操作进行拦截然后处理，我们的数据范围就是使用的com.gaochao.oa.module.com.dependence.server.service.impl.DataruleHandler，这是一种职责链的设计模式。网上提供的插件，也就是interceptor方案我们的系统里已有，即是对所有一般使用oaGrid的后端统一的分页处理：com.gaochao.platform.orm.mybatis.PagingIntercept，代码如下：

　　如前所述，当我们有start、limit时，该方法使用start\limit进行分页，如果没有传入，相当于不分页；该拦截针对的所有query方法

我们的高级查询也是已有拦截的，只是因为我们没有传入start\limit，默认不分页；另外G在做前端伪分页时采用了拼接columns的方法将columns传入，但在接下来的处理是查询所有，然后在前端使用原生的kendogrid进行类似table的动态拼接即newCreateDyTable方法。这种方法是将结果一次查出，分页展示。结合PagingIntercept和G的columns拼接方法，我们只需要简单修改高级查询的查询逻辑，传入start、limit等分页元素，前端完全复用一般模块的gird。这种分页是后端的分页，且不用增加太多的代码。可以肯定，在同样的sql和数据量的情况下，这种分页要比不分页或前端分页给用户的体验更佳，等待时间更短。