WebX實踐指南請求處理一

通過webx入門指南，相信大家都能開始嘗試新增自己的處理頁面了。基本上能夠完成簡單的頁面設計了。我們通常說**是b/s架構的，那這種模式只要掌握前後端的分工和互動，就能游刃有餘。因此，本節就從前後端互動方式來說明如何實現高效的**設計。

**的前後端互動，都是通過http協議實現的，因此**的前後端互動也是在http協議下展開的，因此前端的互動模式也受限於通訊協議，標準的協議中支援的請求方式有get、post、put、delete、head、options。webx框架中通過servlet來處理具體的業務邏輯處理。關於servlet的知識，後面講解webx原理時，再做說明。

head：本質上和get一樣，不過請求中不包含資料資訊

put: 提交請求，表單不支援，通常要指定資源的位址

post: 向服務端提交資料

delete: 用於刪除資源檔案，很少用

options: 詢問服務端支援的請求方式，請求的結果儲存在allow的協議頭中。

每一次http請求，通常都有對應的http響應，訊息返回結果通常包含request處理的狀態資訊，以及返回結果的格式資訊。

返回結果支援的格式有（context-type）種類很多，常見的有：

[參考]：

常見的**格式型別如下：

text/html ： html格式 text/plain ：純文字格式

text/xml ： xml格式

另外一種常見的**格式是上傳檔案之時使用的：

multipart/form-data ： 需要在表單中進行檔案上傳時，就需要使用該格式

對乙個http請求，使用者只需要通過解析request請求，並返回處理結果response。只不過這裡的request和respose是滿足http協議的訊息。因此，大家可以簡單地把這個過程理解成乙個函式呼叫:

response get/post/ (request request);
//把request, response簡單地理解成遵循http協議的結構體

webx中處理請求是通過module來實現的，包括了screen、control以及action三類。具體的實現中是通過httpservletrequest、httpservletresponse以及httpservletsession物件來完成的。當然webx的實現中，對相關的servlet進行了其他的處理。後續的文章中再講解。

webx中請求響應處理時，之前的使用都是從頁面驅動來認識的。現在從request/response角度看下。只需要在對應的module物件中注入servlet物件就可以使用了。關於物件注入可以去看下spring相關的知識。

舉例說明：

場景：通過http://localhost:8081/user/get_user_name.do?userid=10000，獲取使用者名稱

在講解**實現之前，對上述的url路徑做下解析，webx在處理該請求時，會對該路徑進行解析，獲取對應的target，用於載入對應的處理方法。這裡target字尾是.do，預設的會去查詢對應的screen/action物件。查詢時，對於該路徑可能的兩種解釋是 user下的getusername物件或者是user物件的dogetusername方法。webx會先按第一中方法解析，失敗後換第二種方法解析，如果再找不到對應的方法，報錯。在之前的screen物件中我們看到的物件方法往往只有乙個 execute()方法，實際上在呼叫乙個物件時，如果不指定物件的方法名，預設採用的就是execute方法。

實現：/screen目錄下新建乙個user物件，實現getusername(int userid)方法

public
class
user 
}

public
class
user 
}class userresult 
public
void
setstatecode(int statecode) 
public string geterrormsg() 
public
void
seterrormsg(string errormsg) 
public string getname() 
public
void
setname(string name) 
}

可以看到以上兩種互動中和以往的頁面驅動設計是不同的，以往的頁面驅動的場景多是獲取頁面資源，而這兩個場景更多的是提交任務，反饋結果，更類似於函式呼叫。具體的使用中這兩種場景多用於獲取物件資料，而不是資源檔案。

action主要用於表單的處理，本例使用了webx示例程式中的註冊來講解。乙個典型的表單包括了一下幾部分：

name="input"
action="/login.htm"
method="post">
username: 
type="text"
name="user" />
type="submit"
value="submit" />
form>

對於 webx中典型的表單：

form/register")" method="post">
$csrftoken.hiddenfield
type="hidden"
name="action"
value="register_action"/>
#set ($group = $form.register.defaultinstance)
hello, what's your name?p>
#if (!$group.name.valid)
$group.name.messagep>
#end
type="text"
name="$group.name.key"
value="$!group.name.value"/>
type="submit"
name="event_submit_do_register"/>
p>
form>

input action值用於表明action物件, submit按鈕中的event_submit_do_register註明處理該表單的方法是doregister()。$group變數是通過webx的form service提供的，需要通過表單配置完成。關於webx服務見後續的詳細講解。接下來設計對應的action物件，其實他和普通的物件也一樣：

public
class
registeraction 
}

這裡先不關注怎麼用，只是說明呼叫的邏輯關係。呼叫之後，怎麼將結果返回呢？這裡只是用了介面跳轉，如果開發者想知道新增乙個使用者是否成功怎麼辦呢？目前沒有發現好的方法,即使可以注入httpservletresponse。這個和action的定位和設計應該是有關係的。action用於頁面表單資料和應用資料的傳遞，以及頁面的跳轉，因此在使用時也盡量以這種方式實現。而且在實際的應用中，大家多是以跳轉的方式來實現的。比如註冊、或者新增新的資料後通過，頁面跳轉回原頁面，重新整理頁面，從而驗證操作的結果，而不需要返回乙個成功的標誌。這一點不知道讀者怎麼理解？

通過對action、control、screen的介紹中，相信基本的使用場景和場合都有所了解了。對於一般的get請求，使用templates和screen module就可以完成基本的頁面渲染。對於一些業務資料的處理和返回，資料資源的查詢可以通過screen返回值或者response write的方式完成。對於設計資料的增、刪、改操作，通過表單實現，這裡的缺陷是，如何將操作的結果返回給客戶端。

好吧，這裡就不再總結各種場景了，上面的講解中都有涉及到，就不再贅述，讀者可以自己再整理整理。通過對互動場景的介紹，前後端的**互動就有了，接下來就單獨看看前後端開發的一些技術。

WebX實踐指南請求處理一

STL實踐指南一

《資料整理實踐指南》一導讀

iOS事件處理指南（一）

WebX實踐指南 請求處理 一

STL實踐指南 一

《資料整理實踐指南》一導讀

iOS事件處理指南（一）

相關推薦

WebX實踐指南請求處理一

STL實踐指南一