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 的設計目標（儘可能經過最少的代碼把功能實現）