3、敏捷开发框架-查询页面模型-QueryPage 再认识

在复杂的页面看看清问题的本质：

下面的页面，我说其实一部分是编辑页面

 

好吧，咱们一块儿来找到这个编辑页面

 

咱们经过实例来进一步分析

这个页面是，用户列表或者用户编辑画中点击用户【设置角色】弹出来的功能页面

左侧是待选择的角色信息，右侧是已经分配给 用户的 角色信息

 

界面效果以下：

前面咱们了解了两个很是经常使用的页面模型  查询页面模型、编辑页面模型

这是什么页面模型，难道是第三个页面模型，左右选择页面模型，穿梭页面模型

哪来那么多页面模型，若是页面模型太泛滥，都是模型，就都不是模型了。

 

把上面的截图一半

很熟悉，

这不就是查询页面吗？

右侧也截图下：

好像也是查询页面，不过只是缺乏个查询按钮而已

 

按照前面的学习，实现这样一个查询页面是否是很容易的事情嘛

 

先看视图结构

 

隐藏域：UserId 用来存储当前对哪一个用户进行设置的，这是URL参数传过来的

编辑区 分 left 中间功能按钮区  right

 

展开看看，

left 的确就是一个查询页面的结构

    标题、查询条件form、查询按钮、查询表格

 

两个查询页面模型的实现

两个查询，本质上都是查询 role 因此api都是调用 roleSearch API 只是增长类别的区分

pageLeft 查询 未绑定 用户的 角色

pageRight查询 已绑定用户的角色

 

页面配置了 search:true  打开页面当即查询

这样查询功能就都实现了。

下面就来分析下其它功能的开发，在开发以前咱们要套模式，为何要套用前面介绍的

ECIAction动做模型，由于经过前面的介绍，发现已有的模型可以以简单不到不能简单的代码实现功能

既然如此，那么咱们就要对咱们的全部开发功能就行归类思考。以期用高效的行之有效的模式解决问题

 

回顾下，第一个课的画面

红色框内的操做模式，          咱们定义为  行内 操做模型   操做对象是 当前行的主键

蓝色框内的操做模式，          咱们定义为  批量 操做模型 （对表格控件的批量）操做对象是选择的多笔主键

还有就是 编辑页面上的 按钮 咱们定义为  编辑 操做模型   操做对象是当前编辑的主键

 

 

有了上述的三种EciAction模型做为操做行为的基础，咱们要来解构咱们新任务下的操做行为

如上图：

左右红色按钮是 行内操做模型

中间蓝色按钮   实际上是批量操做模型，不过是按钮的摆放位置，放到了页面中间而已。

【添加角色】操做的对象是左侧的列表

【移除角色】操做的对象是右侧的列表

这样来看，是否是就容易实现了。

 

咱们先来看

 

左侧操做模板列 增长 【添加角色】按钮 调用方法 addRole

这是一个行内操做模型

解释下代码，调用后台 UserAddRole API  经过Action模型，自动帮咱们将 当前行上的 RoleId 传递到后台

在咱们这个场景中，是对用户增长角色，因此请求API的时候须要传递上 UserId

这个是任何操做模型都抽象不了的，抽象不了的东西就交个业务去实现，经过在调用Execute以前调用prepare方法

意思是准备，准备后再调用。

 

如今执行完毕以后，须要将左侧和右侧的列表都从新查询一下，那就经过then函数注入 request 的onSuccess 方法接管处理过程

 

下面来实现【添加角色】

 

DOM：

 

先归类，这是一个 批量动做模型 

 

代码和上面是同样，就是mode改为 batch 意思是批量动做模型

这样是否是实现很是容易

 

同时看下右侧的【移除角色】的代码

和上面的代码，除了API的差异外，就是 操做的目标对象是 pageRight

 

 

下面来实现【设置机构】

 

 

至此功能，大致都实现了

这是咱们一块儿好好审视下右侧

右侧咱们看到的是也是一个查询模型

有表格，红色框线部分隐含一个 查询form，默认条件是 页面传过来的 USERID

那么上面，蓝色框线部分 算啥。

看看用户编辑：

上面是用户编辑

 

看下面的地址 

传入的也是 UserId

 

抛开全部的干扰项

咱们只看到这块画面 其实这就是一个编辑页面模型，不过编辑显示的内容比较少，没有了保存、新增按钮

可是要看清本质。找到对应的 页面模型。

那么代码就好实现了。

那么分析透彻了以后，实现只须要两行代码

想要一行也行

到此，这个相对复杂一点的画面也实现了

 

文章开头说的，编辑页面找到了

不是纯粹为了找到编辑页面，

而是看清问题的本质，发现它其实就是编辑页面模型，用编辑页面模型的代码解决问题

 

通过咱们的分解，实际上是两个查询页面模型+编辑模型的组合

 

后面咱们会继续看，是否大部分的页面开发就用咱们抽象的 几个页面模型 就能解决全部问题。拭目以待。