用戶端的JavaScript指令碼中擷取伺服器端控制項的值 及ID

ASP.NET 拾萃——伺服器端控制項篇（一）
技巧一：在用戶端的 JavaScript 指令碼中擷取伺服器端控制項的值

以前，當我們需要在指令碼裡訪問頁面內一個對象的時候，一般都是通過對象的 id 或 name。就像這樣——
<!--Test.html-->
// ...
function getText()
{
  return document.form1.Text1.value; // Text1就是對象的 id
}

// ...

<INPUT id="Text1" type="text" ...>

現在，ASP.NET 讓我們越來越習慣使用 TextBox 作為使用者輸入的途徑。如果我們想在用戶端指令碼裡訪問一個 TextBox，原先的做法就行不通了——
<!--Test.aspx-->
// ...
function getText()
{
  return document.form1.Text1.value; // Text1還是對象的 id？
}

// ...

<asp:TextBox id="Text1" .../>

瀏覽頁面時，會有一個指令碼錯誤——“Text1對象不存在”。原因就在於，Text1作為伺服器端控制項 TextBox，在被發送到用戶端之前，先由.NET Framework 進行轉換，而它的id顯然也是轉換的一部分。如果你在用戶端查看頁面的原始碼，你可以發現原先的 Text1已經不存在，取而代之的是一個普通的 INPUT——
<input name="Test:Text1" type="text" id="Test_Text1" />

這就是轉換的結果，id 不再是設計時所指定的 id。如果我們要在用戶端訪問這個文本輸入框，也必須改變訪問的 id。如何改變？直接將
document.form1.Text1
改為
document.form1.item("Test_Text1" // 保險起見，使用 item 由 id 或 name 得到控制項
或者
document.getElementByID("Test_Text1"  // 保險起見，使用 getElementByID 由 id 或 name 得到控制項

可以嗎？當然可以！只要你的控制項 id 固定是"Text1"。
但是，只有這個條件還不夠。"Test"又是什嗎？它也應該被考慮在內（幸好 form 的 id 不會改變，否則要關心的內容又會多一個）。
你或許已經看出，Test 就是這個 Web 頁面的名字。對嗎？——不完全對
確切地說，控制項轉換後 id 中的"Test"是其所在的 Web Form對象的 ClientID。所有的 ASP.NET 對象都在伺服器端有一個執行個體（如果你物件導向的基礎不夠，建議也補完一次吧），而這個"Test"，就是這個頁面執行個體對象的 ClientID。而 ClientID，則是每個 Web Form頁的一個屬性，它指明了這個Web表單在用戶端的標識。
為什麼要這麼複雜？道理很簡單，我們並不能在用戶端指令碼裡確定頁面的 ClientID 和控制項的 ID。
那應該怎樣做呢？
“在伺服器端代碼裡產生用戶端 JavaScript。”——似乎非常複雜，其實並不困難，只要在伺服器端 Page_Load 事件裡加上（在 IsPostBack 判斷之外）——
RegisterStartupScript("start",
   "\n<script>\n" +
   "function getText()\n" +
   "{\n" +
   "   return document.forms(0).item('" + this.ClientID + ":" + this.Text1.ID + "');\n" +
   "}\n" +
   "</script>\n";

RegisterStartupScript 是 Web Form（System.Web.UI.Page 類）的一個方法，作用是在產生的頁面裡註冊用戶端指令碼。
在這裡，我們添加了一個 getText()函數，作用和之前的 getText()一樣，所不同的在於，它所訪問的控制項 id並非指令碼內指定，而是在伺服器端根據頁面的 ClientID（this.ClientID，this就是頁面自己）和 Text1控制項的 ID（this.Text1.ID）動態產生的。
編譯之後重新瀏覽，我們會在新的頁面原始碼裡找到這個由伺服器端代碼產生的 JavaScript 函數。此時，在頁面的其他地方調用 getText()函數就將正確得到 Text1中的內容了。

ASP.NET 拾萃——伺服器端控制項篇（二）
技巧二：掌握控制項的用戶端屬性及事件

經常在網上看到類似的問題：如何讓 ASP.NET 伺服器端控制項響應用戶端事件？

ASP.NET 伺服器端控制項能夠響應伺服器端事件，使我們能夠像編寫 Windows 程式一樣編寫網頁。可有時我們並不需要讓用戶端啟動並執行控制項和伺服器發生互動，這樣做的開銷是很大的：不僅佔用網路頻寬、伺服器的CPU 資源，還會產生一次 PostBack 導致用戶端瀏覽器“重新整理”影響介面效果。
如果直接在 Web Form的 HTML 程式碼內為伺服器端控制項添加用戶端事件代碼，就像這樣：
<asp:Button id="Button1" OnClick="window.alert('按鈕被按下了')" Text="按鈕1"/>

你會發現，當按下這個按鈕時，並沒有預定的訊息框彈出，而是直接執行伺服器端代碼內的響應按鈕按下事件的 Button1_Click 方法（假設我們已經為按鈕綁定了這個事件）。如果查看用戶端頁面的原始碼，按鈕的 OnClick 事件裡，根本沒有自己寫的代碼，卻變成了"JavaScript:__doPostBack(...)"。
其實這正是.NET Framework 轉換工作的一部分。有了這個"JavaScript:__doPostBack(...)"，才能實現按鈕提交、伺服器端響應事件等一系列動作。（關於這段自動加上的指令碼，我會在今後的文章裡詳細說明。）
想要控制項在用戶端就響應事件，必須另尋他法。好在.NET 已經為我們提供了豐富的介面去實現這些功能。
所有的伺服器端控制項（Button、Label、TextBox……）都有一個屬性 Attributes——這是一個很重要的屬性，它是伺服器端控制項在用戶端對應 HTML 元素屬性及事件的集合。有了它，我們能夠自訂伺服器端控制項在用戶端的行為、外觀。
還是剛才的 Button1，這次我們在 Page_Load 事件裡加上這麼一句（在 IsPostBack 判斷之外）：
Button1.Attributes.Add("onclick", "window.alert('按鈕被按下了')";

重建項目之後再次瀏覽頁面，這次我們終於能夠看到“按鈕被按下”的訊息框被正常彈出了。
回過頭來解釋這句代碼：Attributes 是 Button1也是所有伺服器端控制項擁有的屬性，Add(...)是 Attributes所屬的一個方法，作用是為控制項在用戶端的HTML標記內添加代碼，第一個參數是屬性的名稱，第二個參數是屬性的值。在這裡我們為按鈕的 onclick 事件添加了一段彈出訊息框的代碼。在用戶端查看頁面原始碼，可以看到按鈕的 onclick 事件裡包含了這段代碼（.NET Framework 自動產生的"__doPostBack(...)"就跟在後面，我們使用 Add 就是告訴.NET Framework：“先加入我們的代碼！”）。

Attributes 還有另一種訪問的形式（C#專用）：
Button1.Attributes["onclick"] = "window.alert('按鈕被按下了')"; // []內是屬性的名稱，等號右邊就是屬性的值

這個方法同樣可以用於使用伺服器端代碼為控制項改變屬性：
Button1.Attributes["style"] = "fontsize: 9pt"; // 改變控制項樣式的字型為9磅