在复杂的页面看看清问题的本质：
下面的页面，我说其实一部分是编辑页面
好吧，我们一起来找到这个编辑页面
我们通过实例来进一步分析
这个页面是，用户列表或者用户编辑画中点击用户【设置角色】弹出来的功能页面
左侧是待选择的角色信息，右侧是已经分配给 用户的 角色信息
界面效果如下：
前面我们了解了两个非常常用的页面模型 查询页面模型、编辑页面模型
这是什么页面模型，难道是第三个页面模型，左右选择页面模型，穿梭页面模型
哪来那么多页面模型，如果页面模型太泛滥，都是模型，就都不是模型了。
把上面的截图一半
很熟悉，
这不就是查询页面吗？
右侧也截图下：
好像也是查询页面，不过只是缺少个查询按钮而已
按照前面的学习，实现这样一个查询页面是不是很容易的事情嘛
先看视图结构
隐藏域：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
抛开所有的干扰项
我们只看到这块画面 其实这就是一个编辑页面模型，不过编辑显示的内容比较少，没有了保存、新增按钮
但是要看清本质。找到对应的 页面模型。
那么代码就好实现了。
那么分析透彻了之后，实现只需要两行代码
想要一行也行
到此，这个相对复杂一点的画面也实现了
文章开头说的，编辑页面找到了
不是纯粹为了找到编辑页面，
而是看清问题的本质，发现它其实就是编辑页面模型，用编辑页面模型的代码解决问题
经过我们的分解，其实是两个查询页面模型+编辑模型的组合
后面我们会继续看，是否大部分的页面开发就用我们抽象的 几个页面模型 就能解决所有问题。拭目以待。