在物件化的Web應用程式設計概念下，我們越來越少透過Request.form(“物件名稱”)之類的程式碼取得Submit回來的值，因此request物件的應用越來越偏向伺服器端資訊的取得，而非過去ASP參數接收的功能。
但是我們依舊來看一下Request.Form(“變數名稱”)這樣的語法在ASP.NET上的應用。
我們建立一個Web應用程式，在Web From上面佈置一個TextBox和一個Button：
我們在Button的Click事件中，輸入上圖中的程式碼：
0001: Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click 0002: Dim msg As String 0003: 0004: msg = Request.Form(Me.TextBox1.ClientID) 0005: Response.Write(msg) 0006: End Sub |
請順便注意，我們從這個程式碼中開始用到了變數定義，並且賦予變數型態，過去我們在ASP程式設計中，變數是沒有型別的，如今在ASP.NET中有著清楚的型別定義：
0002: Dim msg As String |
我們在程式的第4行，透過『Request.Form(Me.TextBox1.ClientID)』取得使用者在這張網頁上的TextBox1控制項裡面輸入的值。當使用者在網頁上的控制項中輸入好了值，並且按下按鈕後，值會透過Submit動作傳回來，和過去ASP時代一樣，我們可以利用Request.Form(“TextBox1”)來取得傳入的值。
但是您有沒有注意到，我們在程式中卻是寫著：
Request.Form(Me.TextBox1.ClientID) 而非 Request.Form(“TextBox1”) |
事實上Me.TextBox1.ClientID，傳回的名稱就是TextBox1，代表著是Me(Web From)上面TextBox控制項的ClientID。所謂的ClientID就是該控制項傳到使用者端的瀏覽器上的時候，網頁HTML碼的<Form>標記裡面的<input name="TextBox1" …>的HTML控制項名稱。
這個名稱在預設的狀況下會和我們在Web From上面佈置TextBox控制項時，Visual Basic.NET幫我們預設的名稱一樣(您當然也可以在屬性視窗中修改該物件的名稱，修改後，ClientID傳回的名稱當然也會跟著改變)。
既然這樣，我們為何不直接寫Request.Form(“TextBox1”)，而偏要大費周章的寫Request.Form(Me.TextBox1.ClientID)呢？
這是因為，在某些特定的狀況下，ClientID會不等於控制項名稱，雖然絕大部分是相同的，但是有少數幾個狀況會例外，例如我們利用Pagelet(使用者自訂控制項，一種類似#Include的做法)時，ClientID就會不同。
但是因為目前我們尚未介紹過，因此先不談這個部分，我們在後面會有一個章節來介紹，現在，您僅需要記得設計程式時，必須以『控制項名稱.ClientID』來取得Client端的物件名稱即可。
這個程式執行後會如下圖，當您按下Submit按鈕之後，Button1_Click事件中的程式會被執行，顯示出您在TextBox中輸入的文字：
如此您會發現，實際上Request.Form依舊可以使用，只是我們在ASP.NET中已經不需要(也不應該)再這麼使用，而應該改用先前我們介紹過的『物件化網頁設計方式』取代Response.write和Request.Form。
不建議使用Rquest.Form(參數名稱)，並不代表著Request(參數名稱)也不應該使用。反倒是因為Request(參數名稱)並不會破壞Web From的物件化網頁設計架構，因此，我們在ASP.NET專案中使用Request(參數名稱)的機會還比Request. Form (參數名稱)來的多了。
我們可以透過Request(參數名稱)來取得網頁以HTTP GET方式傳入的參數。
所謂的HTTP GET參數傳送方式，指的就是當使用者在瀏覽器端以『Http://www.studyhost.com/test.aspx?no=10&flag=true』此類的URL傳入的http request，稱之為HTTP GET，而一般以表單<Form>的方式Submit回來的參數，我們稱之為Http POST。 |
我們看底下這個例子，我們僅在程式的Page_Load事件中，撰寫一行指令(第3行)：
0001: Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 0002: '在此加入要初始化頁面的使用者程式碼 0003: Me.TextBox1.Text = Request("DefaultValue") 0004: End Sub |
當我們在網址列中輸入底下的URL以啟動網頁時：
http://localhost/AspxDemo/Chapter02/Request/request.aspx?DefaultValue=測試 |
網頁執行的結果就會是：
Web From確實會在Page_Load事件中取得經由網址列(HTTP GET)傳入的參數，並透過第3行程式設定為TextBox1的預設值。
備註： |
請注意，當您執行此範例時，必須將專案中『Web.Config』檔案裡的globalization設為『BIG5』，才能正常執行。 |
4-6-3 Request.系統參數
Request失去了過去取得參數的主要功能後，反倒是其他的能力在ASP.NET中被擴充與加強了，我們看底下網頁的執行結果：
上面這個網頁顯示了許多與瀏覽器或是系統相關的資訊，這些資訊都是透過Request來取得的。該網頁的程式如下，我們僅在網頁上佈置了一個Literal物件，然後透過Request與得相關資料組成Msg字串，最後將Msg字串指定給Literal1物件：
0001: Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click 0002: Dim msg As String, i As Integer 0003: 0004: msg += "<BR>Browser 狀態：" 0005: msg += "<BR> 是否支援 ActiveXControls：" & Me.Request.Browser.ActiveXControls 0006: msg += "<BR> 是否支援 Cookies：" & Me.Request.Browser.Cookies 0007: msg += "<BR> 是否支援 JavaApplets：" & Me.Request.Browser.JavaApplets 0008: msg += "<BR> 是否支援 JavaScript：" & Me.Request.Browser.JavaScript 0009: msg += "<BR> 主版本編號：" & Me.Request.Browser.MajorVersion 0010: msg += "<BR> 次版本編號：" & Me.Request.Browser.MinorVersion 0011: msg += "<BR> 使用平台：" & Me.Request.Browser.Platform 0012: msg += "<BR> 名稱：" & Me.Request.Browser.Type 0013: 0014: msg += "<BR>虛擬路徑：" & Me.Request.CurrentExecutionFilePath 0015: msg += "<BR>檔案路徑：" & Me.Request.FilePath 0016: msg += "<BR>" 0017: msg += "<BR>Http Header數目：" & Me.Request.Headers.Count 0018: For i = 0 To Me.Request.Headers.Count - 1 0019: msg += "<BR> " & Me.Request.Headers.Keys(i).ToString & "：" & Me.Request.Headers.Item(i) 0020: Next 0021: msg += "<BR>" 0022: msg += "<BR>Path：" & Me.Request.Path 0023: msg += "<BR>PhysicalApplicationPath：" & Me.Request.PhysicalApplicationPath 0024: msg += "<BR>PhysicalPath：" & Me.Request.PhysicalPath 0025: msg += "<BR>" 0026: msg += "<BR>URL：" 0027: msg += "<BR> AbsolutePath：" & Me.Request.Url.AbsolutePath 0028: msg += "<BR> AbsoluteUri：" & Me.Request.Url.AbsoluteUri 0029: msg += "<BR> Authority：" & Me.Request.Url.Authority 0030: msg += "<BR>" 0031: msg += "<BR>Host：" & Me.Request.Url.Host 0032: msg += "<BR>HostNameType：" & Me.Request.Url.HostNameType 0033: 0034: msg += "<BR>UserAgent：" & Me.Request.UserAgent 0035: msg += "<BR>UserHostAddress：" & Me.Request.UserHostAddress 0036: msg += "<BR>UserHostName：" & Me.Request.UserHostName 0037: msg += "<BR>" 0038: Me.Literal1.Text = msg 0039: End Sub |
請注意，在VB.NET中，X+=1，代表著X=X+1之意，因此，msg +=”abc”，也就表示著msg=msg+”abc”，這樣程式撰寫起來會比較清晰好看。
而Literal物件我們之前曾經提過，它和Label物件一樣，可以透過Label.Text=”abc”來指定值顯示在Web From上，但是不同之處是，Label是一個具有實體大小的物件，而Literal物件則是不具形體的，這兩個物件的差異我們會在後面介紹控制項的單元在詳細的說明。
至於透過Request物件取出的值，絕大部分都是過去我們在ASP程式設計中常常使用的，包括使用者端瀏覽器的特性、Http Header、URL資訊、網頁絕對位置…等。因此就不再贅述。
但是特別值得一題的是，過去我們想取得ASP網頁的執行路徑，只有request.MapPath("")可用。如今透過Request.PhysicalApplicationPath、Request.PhysicalPath、Request .Path…能夠取得的網頁路徑比過去清楚很多，在設計動態資料庫連結(例如指定Access檔案的位置)、檔案操作(上傳檔案、取得主機上的文字檔內容…等)都相當方便。
Request這些功能過去在ASP當中不是根本沒有，就是不完整，如今在.NET Framework中的環境裡，將其擴充的相當豐富，讀者可以測試這些屬性實際上產生的值，就會發現在.NET Framework中開發Web應用程式，實在比起過去用ASP輕鬆很多：
指令 | 功能 |
request.ApplicationPath | 目前應用程式的虛擬路徑 |
request. Browser | 取得關於要求的用戶端的瀏覽器能力的資訊。 |
request. FilePath | 取得目前要求的虛擬路徑。 |
request. Files | 取得用戶端上載檔案 (Multipart MIME 格式) 的集合。 |
request. PhysicalApplicationPath | 取得目前正在執行的伺服器應用程式的根目錄之實體檔案系統路徑。 |
request. PhysicalPath | 取得對應到要求的 URL 之實體檔案系統路徑。 |
request. RawUrl | 取得目前要求的原始 URL。 |
request. Url | 取得關於目前要求的 URL 的資訊。 |
request. UserAgent | 取得用戶端瀏覽器的原始使用者代理字串。 |
request. UserHostAddress | 取得遠端用戶端的 IP 主機位址。 |
request. UserHostName | 取得遠端用戶端的 DNS 名稱。 |
備註： |
不應該這麼做是因為如果依舊使用Request.form和response.write會破壞整個ASP.NET的Web應用程式設計架構，將失去物件導向程式設計的便利性和結構性，況且，由於Web From物件所傳遞到Client端的網頁是被.NET Framework解析過的，因此控制項的ClientID確實不見得一定會等於您在程式中設定的控制項名稱(後面介紹Pagelet)時會有清楚的說明。因此儘管您可以用Request.Form(控制項名稱.ClientID)來取得正確的Submit值，但如此不僅大費周章，且多此一舉。在ASP.NET中，還是乖乖的使用微軟建議的物件化網頁設計方式，才是最好的選擇。 |
沒有留言:
張貼留言