|
在前兩篇文章中，我們實現(xiàn)了AppInventor與Node-RED之間的通信，進而實現(xiàn)了對MySQL數(shù)據(jù)庫的新增、刪除、查詢操作。從實現(xiàn)這些功能的順序來看，刪除操作是先后端，后前端。這么說聽起來有些費解，換一種說法：在實現(xiàn)刪除功能時，我們首先在后端——Node-RED中添加了http in（delete）節(jié)點，并設其URL屬性為“/delete”。又在后端——Node-RED中添加了模板節(jié)點（deleteEvent），并設其topic屬性為：“DELETE...”，如下圖所示。在后端設置完成后，再在前端——AppInventor中設置了web客戶端組件的網(wǎng)址屬性：http://.../delete?eventid=...，此時，我們已經(jīng)知道了后端http in節(jié)點的URL屬性為“/delete”，因此，才會有“/delete?eventid=...”這樣的寫法。同樣是前后端協(xié)同工作，在實現(xiàn)查詢及新增功能時，我們采取了相反的順序：先前端，后后端。以查詢功能為例，我們首先在前端——AppInventor中編輯了web客戶端組件的網(wǎng)址屬性，網(wǎng)址的后面是“/query”字串。在前端設置完成后，再在后端——Node-RED中添加http in節(jié)點，并設其URL值為“/query”，然后添加模板節(jié)點，設其topic屬性為“SELECT...”。新增功能的實現(xiàn)順序也是一樣，先在AppInventor中添加組件、編寫代碼，然后再在Node-RED中添加、設置節(jié)點，只不過新增程序使用了POST方法，程序更為復雜而已。從表面上看，我們在討論編寫程序的順序問題：是先實現(xiàn)前端，還是先實現(xiàn)后端，但實際上，我們真正關注的是前后端的協(xié)同問題。如果一個開發(fā)工程師既可以寫前端，也可以寫后端，那么他被稱為“全棧工程師”。當一個人獨自完成前后端開發(fā)時，就像我們現(xiàn)在這樣，則開發(fā)的順序沒有一定之規(guī)，完全可以隨個人的習慣。但是，當前后端由兩個人，或兩個團隊單獨開發(fā)時，最重要的不是順序，而是規(guī)則，必須首先制定規(guī)則，約定好前后端的接口名稱、請求方法及數(shù)據(jù)規(guī)格。例如，在實現(xiàn)刪除功能時，必須約定好“delete”這個接口名稱，約定GET方法，同時約定好數(shù)據(jù)的組織方式，例如，在刪除URL中參數(shù)的寫法：“?eventid=...”，等等。無論是全棧開發(fā)，還是團隊分工開發(fā)，理想的做法是，在動工之前先編寫設計文檔，約定好前后端的接口名稱、請求方法以及數(shù)據(jù)規(guī)格，以避免出現(xiàn)“驢唇不對馬嘴”的低級錯誤。以上是針對前后端開發(fā)規(guī)范的陳述，下面我們繼續(xù)實現(xiàn)項目中的數(shù)據(jù)修改功能，我們采取的策略是：先前端，后后端。采取這一策略的原因是，前端任務重，后端任務相對簡單。在AppInventor中打開上一篇文章中創(chuàng)建的項目，我們即將為“修改”按鈕編寫點擊事件處理程序。在開始編寫程序之前，需要簡單說明一下“修改”的操作流程。 開發(fā)工作已經(jīng)過半，但我們還從未給出過『特事特記』應用的功能說明，現(xiàn)在借此機會，對應用的頁面邏輯加以敘述。按照應用執(zhí)行的時間順序，依次實現(xiàn)如下功能。 屏幕初始化時，自動填寫當前日期，禁用刪除、修改、新增按鈕； 當用戶開始輸入事件信息時，啟用新增按鈕； 當用戶點擊查詢按鈕時，顯示查詢結(jié)果； 當用戶選中一條事件記錄時，將事件信息填寫到對應的文本框中，此時啟用刪除及修改按鈕； 當用戶點擊刪除按鈕時，彈出對話框，詢問用戶是否確定刪除，用戶可以選擇刪除，則執(zhí)行刪除操作；用戶也可以取消刪除。 當用戶點擊修改按鈕時，執(zhí)行修改操作。 刪除或修改完成后，重新查詢數(shù)據(jù)庫，并顯示新的事件列表。
基于以上描述，需要在項目中添加一個對話框組件。同時，我們約定修改功能的接口名稱是“update”，web客戶端請求的方法是POST，傳遞的數(shù)據(jù)格式是鍵值對列表（與新增功能完全相同）。 下面依次實現(xiàn)上述功能。 ①屏幕初始化，代碼如下圖所示。 ②啟用新增按鈕。偵聽文本輸入框的失去焦點事件，并設置新增按鈕的啟用屬性，代碼如下圖所示。 ③顯示查詢結(jié)果。增、刪、改之后，提示操作成功，并查詢新數(shù)據(jù)，代碼如下圖所示。 ④選中一條事件記錄。當用戶在事件列表里選中一個事件時，將事件信息填寫到文本框，同時啟用修改、刪除按鈕。 ⑤刪除事件記錄。用上一步中取到的選中項id替換刪除網(wǎng)址中的固定eventid。 刪除或修改記錄后重新查詢?nèi)渴录涗?，這時，應該將選中項id值重新設為0。⑥修改事件記錄。修改操作與新增操作有很多相似之處，如請求方法為POST，數(shù)據(jù)格式為鍵值對列表，不同之處是，修改操作的接口名稱為“update”，而新增操作接口名稱為“insert”。因此，在AppInventor中，修改和新增兩項功能所使用的程序幾乎是完全相同，我們將此前的新增程序封裝為過程，用參數(shù)來區(qū)分不同的操作類型。代碼如下圖所示。注意上述程序中的不同：①接口名稱不同；②新增操作時，eventid取系統(tǒng)時間，而修改操作時，eventid取原有記錄中的eventid值。至此我們完成了前端的開發(fā)，現(xiàn)在轉(zhuǎn)戰(zhàn)到后端，在Node-RED中添加兩個節(jié)點：http in及模板。設http in節(jié)點的名稱為“update”，URL為“/update”，請求方法為“POST”；設模板節(jié)點的topic屬性為“UPDATE events SET e_date=..., ... WHERE eventid=...”，程序如下圖所示。注意，上圖中為了展示完整的SQL語句，對語句進行了換行，稍后正式發(fā)布時，需要取消換行。上述設置完成后，將兩個新節(jié)點連接到此前的mysql節(jié)點，并點擊Deploy按鈕讓程序生效。至此，我們完成了修改功能的后端程序，接下來可以開始測試了。由于程序的功能較為復雜，這里只展示一個測試結(jié)果，針對各項功能的完整測試，就留給讀者自己來完成。至此，『特事特記』已經(jīng)實現(xiàn)了全部預設功能。
|
