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

 

拋開全部的干擾項

咱們只看到這塊畫面 其實這就是一個編輯頁面模型，不過編輯顯示的內容比較少，沒有了保存、新增按鈕

可是要看清本質。找到對應的 頁面模型。

那麼代碼就好實現了。

那麼分析透徹了以後，實現只須要兩行代碼

想要一行也行

到此，這個相對複雜一點的畫面也實現了

 

文章開頭說的，編輯頁面找到了

不是純粹爲了找到編輯頁面，

而是看清問題的本質，發現它其實就是編輯頁面模型，用編輯頁面模型的代碼解決問題

 

通過咱們的分解，實際上是兩個查詢頁面模型+編輯模型的組合

 

後面咱們會繼續看，是否大部分的頁面開發就用咱們抽象的 幾個頁面模型 就能解決全部問題。拭目以待。