咱们再次来一块儿研究下 QueryPage 查询页面模型框架
通常状况下咱们遇到的比较多的，查询模型就形以下图的函数
查询条件+查询表格+分页 的组合编码
图一spa
下面咱们看下图设计
图二orm
咱们先来找不一样，很是明显，就是一个是表格，一个是图表事件
总的来说就是彻底不一样的内容ci
接着咱们来找相同，都有一个查询按钮、都有清空开发
都有 查询条件 form回调函数
从这个角度看，和图一是同样的。
那好咱们就将这样的页面也归类为查询页面模型，能否。
前面讲过，咱们经过抽象总结出来的 几类业务模型就能解决咱们系统开发问题。
不是纯粹为了必定要纳入某个模型，而是要看这个模型是否有利于这样的页面开发，也就是用这样的模型来开发
是否开发变简单了，一切以研发人员的用户体验为目标。
查询页面模型，
从应用的角度进行 子类mode的归类
目前归为两个
table 表格模式
notable 非表格模式
实现代码如上图
经过QueryPage 注册查询API，经过QueryPage模型，自动实现查询功能（无需编码维护查询的实现）
只管注册 searched 回调函数来处理，查询后的结果。
注意这里设置 mode=notable
这样对于图表类的查询页面就实现了。
一样作另一个页面：
实现代码以下：
回到前面的问题，是否有利于研发人员 代码更加简洁了。
为何要归类：
归类的意义在哪里？
下图是原来的代码，
是否变的更简便了，那就须要有个比较。若是不这么作，那么代码该如何实现
如上图的代码：
第一：咱们要本身实现一遍 btnClear 这个重置查询条件的 按钮事件吧。虽然也不是太难，由于框架设计就是不难
在容易和不写代码之间，咱们选择不写代码
第二：看queryData的代码
一是，查询按钮要注册 onclick="queryData()";
二是，查询按钮的实现 要本身构建 EciRequest请求
本身经过form组件获取查询条件
虽然也不难，仍是不想写！
不想写就对了，这个状况下的“不辞辛苦”其实不是太好！
此时强烈提倡“偷懒”，不付出太多代价又完美的解决了问题，岂不快哉！