asp.net 2.0 新控制項介紹使用方法

.NET 2.0 新的控制項及其用途。

    一、Data Source Controls

    SqlDataSource：兒童玩具型資料來源，它就像你平常做的資料訪問類一樣，不過只需要設定它的一些屬性就可以工作了，並且它和其它的資料顯示控制項很好的合作。因此還是很方便的。如果有了VS還不懂用這個玩意兒，那麼可以直接去幼兒園進修了。

    ObjectDataSource：企業級解決方案，不用再為UI層煩惱了，如果你做基於資料庫的應用。可以輕鬆地把您的資料訪問層或者業務層綁定在這個可愛的東西上面了。它用起來就像上面的兒童玩具一樣的方便。真是瑪麗顧得啊。  

    還有XmlDataSource和SiteMapDataSource來綁定於XML檔案或網站地圖（後面會提到，預設也是XML格式的），還可以使用XPath從中選擇，或者直接使用XSLT轉換XML（XmlDataSource）

    忘記了還有另一個兒童玩具AcceseDataSource。不要小看兒童玩具哦，多啦A夢...

    二、New Data Bound Controls

    GridView：新的表格型資料控制項，用來取代DataGrid。實際上，在VS2005中的工具列上已經預設沒有DataGrid了，可能是無地自容了。簡單的說，GridView就是一個傻瓜式的DataGrid，不必再為一個簡單的分頁或者其它的什麼功能寫一大堆代碼了。一個屬性就擺平了。並且它的列更加豐富。為了區分DataGrid的Column屬性，它的列都叫Field了，真不知道萬一還有新的需要，3.0中會叫什嗎？

    DetailsView：如果做一個資料表的維護，那麼就會有這樣的東西，無聊地編寫增加和個性的頁面，並且寫一大堆更無聊的代碼。那麼現在DetailsView就是其中的一個不錯的解決方案了。終於解放了啊。DetailsView就是一條記錄的資料控制項，可以增加和修改，還可以翻頁。

    FormView：可以把它當作DetailsView的自訂版本了，在下面的綁定中介紹。

    三、Data Controls Parameter

    就是上面那些Data Source的參數，有多種，就不一一解釋了，僅將其列出。其中如果Data Source和Data Bound Controls共同使用時，參數名是有限制的。Parameter（靜態）；QueryStringParameter；ControlParameter；SessionParameter；FormParameter；CookieParameter；ProfileParameter。

    四、Improved Data Binding Syntax

    新的Binder 方法<%# Eval(...) %>和<%# Bind(...) %>，不需要再有Container.DataItem了，因為這兩種方式只能用在資料繫結的容器內。其中Bind為雙向繫結，可以從資料來源Data Source綁定到Data Bound Control，而可以從資料顯示控制項返回到資料來源控制項。

    五、豎向控制項

    即新的控制項TreeView和Menu，Menu就像微軟網站上的那個菜單，TreeView就是MSDN的那種樹狀方式，而實際上TreeView也可以實現像MSDN一樣的分塊讀入，但是沒有實際測試，不知道能不能適用於各個瀏覽器，不過TreeView再不是原先1.1時微軟提供的那個劣質品了。

    2.0的資料繫結完全改變了方式，當然，它還是向下相容的，不過我想新的方式可能確實會給我們帶來相當的便利

 

  在N久之前，還在CSDN上論壇上看到過這樣的說法：ASP.NET的用戶端驗證不安全。然而實際上驗證控制項是在伺服器端驗證的，不管用戶端是否發生了驗證。而像Firefox這樣的瀏覽器更是所有的驗證都是在伺服器上執行的。

    因為1.x版本的驗證控制項是用HTML自訂屬性來實現的，而除IE及IE核心的瀏覽器外，這些特性是不被支援的，因此，在驗證其它瀏覽器的資料時無論如何都只能返回伺服器了。在2.0中，這個特性終於被修改了，雖然看起來有點傻傻的。是的，它確實像我們普通會javascript的人都會想到的一樣，使用javascript為驗證控制項產生的span元素增加屬性。但是，這麼簡單的改動卻使得可以使用用戶端驗證的瀏覽器大大增加了（基本上都可以了）。

    而通過Page的屬性ClientTarget可以設定所有的驗證控制項是否會在用戶端驗證。只要將這個屬性設定為UpLevel就可以了，DownLevel下，所有的驗證都只會在伺服器上執行了。預設情況下，大多數瀏覽器都是會在用戶端驗證的，所以我並不知道它的這個屬性是不是預設UpLevel了。當然，如果要為單獨的一個或幾個驗證控制項設定的話，那麼還是使用原先的EnableClientScript。

    另外還增加了一個SetFoucsOnError屬性。就是當出錯的時候將焦點移到控制項上。這樣就不會使使用者在點擊了按鈕之後因為沒看到錯誤提示而在那發愣了。另外一個小東西就是CustomValidator增加了ValidateEmptyText屬性來讓使用者自訂驗證控制項在值為空白時也驗證。

    下一個有用的特性是ValidationGroup屬性，將你在一個按鈕點擊時要驗證的控制項設定為同一個組名吧，而另一個按鈕要驗證的設定為另一個名，這樣就可以使點擊一個按鍵時只發生期望的驗證，而不是所有的驗證，而不必在伺服器端顯示來控制項。注意，按鈕也應該設計ValidationGroup屬性。

    最後一個就是比較驗證控制項將使用與文化無關的格式。

    驗證控制項的改變從使用上來說沒有多少改變。

  Window XP的樣式終於被可愛的M$搬到ASP.NET中了。這樣的東西讓我想到了M$的恐怖的想法，原先150智商現在被分解了，150智商=微軟解決方案+50智商+已經學會了容忍不完美和失誤。當然，如果您的智商已經是150的LEVEL，那麼使用微軟解決方案可能會導致溢出。（不在討論範圍之內）

    其實用樣式和主題這樣的詞並不能很好的說明ASP.NET 2.0中出現的這些東西。因為它很容易和我們的網頁樣式表css混淆起來。實際上，可以在主題和皮膚中可以定義的絕不僅僅是CSS樣式而已。QuickStart中稱之為伺服器的端的樣式，這樣會更合適一點。在主題和皮膚中，絕大部分的內容都是可以使用定義的，當然不包括Id。

    所有的主題和皮膚都必須放在一個叫App_Themes的目錄下，這個目錄可以是應用程式級的（把它放在你的網站目錄下）或者是全域的（放在.net的目錄下，或者放在IIS的一個目錄下，具體參見協助）。主題實際上就是多個皮膚的集合，在App_Themes下的子目錄名就是主題名。而主題名下的尾碼名為.skin的檔案就是皮膚檔案。

    皮膚檔案的寫法更是傻瓜式的，其實就是把原先寫在控制項下的屬性移至.skin下。寫法和.htmlx檔案基本上是一樣的，只不過沒有Id屬性，卻多了一個SkinId的屬性。不用懷疑，在頁面中使用同樣的SkinId就可以使用這個皮膚定義的樣式了。而在皮膚檔案中沒有使用SkinId屬性的控制項，將是預設應用到頁面中所有沒有指定SkinId的同類控制項上。

    不好意思，忘記了說在Page指令或者程式碼中要顯示指定Theme屬性，屬性的取值就是App_Themes下子檔案夾的名字。另外還有一個StyleSheetTheme屬性，也是同樣的取值範圍。暈乎哉？傳說Theme屬性>頁面中指定的屬性>StyleSheetTheme屬性中指定的屬性。但是例子中上述說法很明顯是成立的。

    不知道大叔大嬸姐姐哥哥們有沒有考慮過，在一個網站中出現N次男、女這類的下拉框時該怎麼辦？在每個頁面寫它的ListItem嗎？綁定資料庫或XML？漫漫的人生就在這樣的思考中消失？如果是這樣的話，那麼你應該開始喜歡上皮膚了，您可以把你的簡單的資料選擇框的內容放到皮膚檔案裡去了。

    在皮膚檔案中甚至可以出現資料繫結運算式！當然這個是很有限的，僅在資料顯示控制項，如DataList，DataGrid，Repeater，GridView等（VS2005工具列中它們被放置在一個單獨的組裡）。並且必須使用新的Eval或Bind運算式，並且不能在皮膚裡執行綁定。

    在皮膚檔案中也可以使用CSS或者圖片等資源，不用擔心路徑問題，M$已經幫我們解決了，當然，CSS使用起來得小心了，因為它可以影響到全域。

    最後，如果要在整個網站使用同一個主題的話，那麼在Web.Config中指定吧。在System.Web下增加這樣的東東<pages theme="ExampleTheme"/>，也可以在代碼中指定主題，但是，是在Page_PreInit中也不是Page_Load中。

    可憐的我正在公司長達兩天的培訓中與無情的睡魔做鬥爭，還能抽空出來寫寫學習筆記，已經很不容易了，請各位大蝦手下留情，thanks！

首先，因為這篇內容很少，所以廢話居多。順便提一下，有空在這兒看我這種閑人的筆記並發表詳論，甚至有空看電腦報的大叔，您不如多發點時間去做點大叔應該做的事吧。本人不僅虛偽，而且不喜歡任何有意義或無意義的批評。Just For Fun！ No Class！

    CSDN不知道是為了強烈證明微軟的SQL SERVER的強健性，每日每夜總要無數次地為我們展現串連池滿的異常提示。為了刪除發表上一篇文章時按了N次F5的後遺症，我再一次NF5，總算把多餘的文章給刪除了。

    上次提到的是主題和樣式，而這回要提到的是Master Page（有稱呼為母頁面或者首頁面的，總覺得不是很清楚，因此使用英文原詞）也是ASP.NET 2.0針對WEB特性的改進之一吧。感覺2.0把普通的WEB特性都引入到伺服器了。Master Page從設計上來看有點像是伺服器端的架構。

    不管是ASP開始的include還是ASP.NET的使用者控制項，都是頁面公用部分的一個解決方案。而2.0引入的Master Page則給了一個更好的選擇。

    Master Page實際上更像Dreamweaver的模板，只不是，它是實際存在的，而不像Dreamweaver只是存在於設計時。Master Page定義了一個共同風格網站的架構，在它的內部使用預留位置來表示實際可以修改的部分。具體文法如下。

    在頁面的聲明中取代Page指令的是Master指令，如<%@ Master Language="C#" %>。Master Page中的文法和普通的頁面並沒有多少差別，不過有一個預留位置控制項。如<asp:contentplaceholder id="FlowerText" runat="server"/>。在預留位置中的內容則是它的預設內容，如果在使用這個Master Page的ASPX頁面中沒有為這個預留位置提供新的定義，那麼它將顯示它的預設內容。為了和普通頁面區分開來，Master Page以尾碼名.master結束。

    在頁面中使用Master Page的方法是在Page的聲明中的MasterPageFile屬性指定Master Page的路徑。在頁面中可以通過定義佔位符的內容來顯示不同的效果。文法如下（例子Copy自QuickStart）：

<asp:content id="Content1" contentplaceholderid="FlowerText" runat="server">
    With sunshine, water, and careful tending, roses will bloom several times in a season.
</asp:content>

    實際上，頁面中如果引用了Master Page，就只能定義佔位符對應的內容了。那麼不同檔案的標題呢？在Page指令中。一個Title屬性指定了每頁的標題。

    Master Page並沒有解決連結的相對路徑問題，非常遺憾，我們還是得使用絕對路徑或者應用程式相關路徑（ASP.NET特定的~）來為不同路徑下的引用解決路徑問題。

    為了在代碼中調用並修改Master Page的內容，在頁面中加入如下指令<%@ MasterType VirtualPath="Site.master" %>。在代碼中使用Master. 就可以調用Master中的內容了，這裡的調用有兩種方法，提供強型別方式的屬性或者直接操作Master Page中的控制項。

    Master Page是可以嵌套的，可以輕鬆為一個網站制定一個總的架構，再為每個部分制定一個更詳細的架構。
在一個Master Page中引用另一個Master Page的文法和Page是一樣的，因此，它也只能包含asp:content這樣的東東了。

    最近的學習都缺少實踐，但是對於（形容詞略去大約500個字）的我來說，it's nothing。如果在實踐後有什麼新的看法，再寫新的筆記吧。