2、敏捷开发框架-编辑页面模型-EditPage

敏捷开发框架：编辑页面模型 

 

编辑页面的开发：

下面以用户管理为例子，进行分析

如上图，就是咱们典型的编辑画面

特色是：上面一排功能按钮

中间是：表单

主要实现数据的编辑、加载、查看、保存、新增 等功能

 

页面DOM结构以下：

从上到下依次看

eci-page-edit 表示当前页面是编辑页面

head 头部 主要放功能按钮，class是 toolbar 若是想要背景为灰色 就增长 eci-gray-bg

eci-edit-area 编辑区  采用编辑区 自适应窗体高度设计  class 加 fit

footer 底部，用来显示操做页面的提示信息

 

编辑的画面功能包括

编辑数据加载

保存

新增

 

代码如何开发：

    使用 EditPage初始化当前编辑页面

    同查询页面同样重要的是 keyField 主键

    这里只要设置 

    loadApi  用来查询当前编辑的数据显示在表单上

    saveApi 用来保存

 

   page.tryLoad( )方法  对应的 EditPage类里面 提供了 load方法

   load方法的含义是  根据keyValue查询数据

   tryLoad 主要是考虑，咱们新增画面和编辑画面是同一个画面

   这里调用 tryLoad 里面会自动识别当前打开画面是新增仍是编辑

   若是是新增就不调用任何后台，若是是编辑，则自动从URL地址中获取当前页面的主键值

   加载到EditPage 的 keyValue中，同时记录到页面的主键DOM中。

   

   经过上述两行代码就实现 编辑页面的全部功能了。

   

   编辑数据加载

   保存     默认ID btnSave  也能够指定  saveId

   新增     默认ID btnAdd   也能够指定 addId

 

点击保存，效果如上图。

通常状况下不须要些任何代码。

用户编辑画面的场景，有点特殊，在新增的时候，那可以选择员工，当变成修改的时候，控制员工放大镜不能选择

上图演示的是新增时，人员放大镜能够选择。

保存后，放大镜不能选择了，这要怎么作。

按照正常这不该该是个问题，保存后控制下呗。在这里的确是个问题了。

为啥，由于我没有写任何代码就实现了保存，那咱们如何应对上面提到的这个问题呢。

 

   如上图：提供saved回调函数，接管了 保存后的处理逻辑

   可是同时保留了 默认回调函数的 消息提示功能。

   这样的设计是为了各司其职，通力协做。

   本能形成下面的困扰：

   默认回调函数内置了 保存成功后的消息提示，这样业务代码就省得写了。

 

  可是在特殊状况下，业务代码需实现本身的回调函数，本身实现回调函数的目的是要加入本身的业务逻辑

  好比上例的，咱们要控制 某个控件的只读属性，可是我要是须要框架帮忙保存，消息提示功能

  不至于我为了实现另一个功能，无可奈何增长另一个段代码实现已经有的功能，这就是反作用。

  

  好的，框架尽最大的可能实现你的须要，让你部分接管回调处理过程。

  你负责处理你的，处理完了，流程继续交给框架来作，这时候框架帮你实现消息的弹出提示功能。

  OK，达成协议。就这么干。

 

  事实上上述的设计不够完善。

  只是考虑到了绝大数的状况，是要求消息提示由框架来作的状况。

  那思考下，有没有一种状况下，业务代码但愿全权接管回调处理过程，不要框架帮我作消息提示的状况呢。

  答案是 确定会有，那种状况下怎么办呢。

  上代码：

  经过设置 response.cancel=true 来取消框架的代码执行，知足极少部分特殊状况的灵活性。

 

 

好的，保存功能咱们实现了

接下来咱们来实现新增功能的代码

默认已经实现了，只要是你的 按钮ID 是 btnAdd 就能够了。

 

EditPage页面内置了 add 方法

下面说说特别的状况：

如上图，这里的新增 btnAdd 咱们给这个按钮增长了事件 addAction

虽然，按钮ID 仍是叫 btnAdd  由于你给它加了事件，那么框架就无论了，全权交给你了

你为何要这么作呢，确定是有缘由的。

例如：个人缘由

是想在 新增的时候又将 员工放大镜设置成 可选择的模式。（框架的代码可管不了这么个性的需求

只能管标准的、统一的处理方式，新增，就所有设置成空）

 

那好由于有特殊的须要，因此须要业务代码来接管处理过程。

框架将add方法包装成独立的方法，这个时候在本身的业务代码中依然能够调用 add方法实现基本功能

+本身的代码块，经过这样的方式来协同。

是否是灵活有方便。

 

至此新增的功能咱们就完成了。

没有特殊状况一行代码都不要，只要ID 命名成 btnAdd 便可

面对特殊的要求时，代码也很是简便

 

继续：实现后面的功能

回顾一下，QueryPage页面的开发介绍

这个功能是否是同样，只是在不一样的画面上，不一样的表现形式

一个是编辑画面，一个是列表行内事件

 

 

在编辑画面上，咱们将查询页面的这两行代码拷贝过来

同样的代码，不作任何修改，功能彻底没有问题

明明是不同类型的画面，最起码，如何取参数都应该是不同的吧。

这就是 EciAction动做模型的强大之处。

 

如上功能是没有任何问题，可是总感受这个界面比较小，不利于操做。

由于自己用户编辑窗口是弹出的小窗口，那么在内部弹出确定很差看。

怎么办？在父窗体中弹出

代码怎么写

 

点击试试：

一样标题也出来了。

 

这个窗体是怎么弹出的呢

请求者是编辑画面     在列表页中经过 eci.open layer弹出     目标页面  UserRole画面

这里涉及   调用者、执行者、目标窗体   三者这间的关系

关于三者之间的信息交互 后面会专题介绍  《ECI弹窗交互设计》

先记住有这个三个概念，便于后续交流。

 

 

最后介绍下

页面结构中的 footer 的做用是啥

 以下图：咱们放置的是 tipContent 内容块  

 提示内容

 

 

 

开发人员怎么写：

如上图，只要在 控件上 加  data-tip属性便可，怎么动态显示到 状态栏上的，由框架统筹控制！

 

 

 

 

========================================================================

至此 EditPage 画面在用户编辑的使用 介绍就到此

其实其它对象的保存，都是同样的。

 

下面截图看下，角色编辑画面的代码，对比下

首先视图

页面初始化：

打开这个编辑页面，若是是新增的时候，将全部依赖 主键的按钮例如  复制、复制权限，设置用户等按钮 失效

page.saved 回调函数，控制当页面保存成功后，将 相关按钮 启用。

 

下面两行是实现【分配权限】、【设置用户】的代码

大部分的行为代码实现 控制在一行上，兑现了 EciAction 的设计目标（尽可能经过最少的代码把功能实现）