vs2005中GridView用来取代DataGrid

ASP.NET 2.0列出新的控件及其用途

一、New Data Bound Controls

    GridView：新的表格型数据控件，用来取代DataGrid。实际上，在VS2005中的工具栏上已经默认没有DataGrid了，可能是无地自容了。简单的说，GridView就是一个傻瓜式的DataGrid，不必再为一个简单的分页或者其它的什么功能写一大堆代码了。一个属性就摆平了。并且它的列更加丰富。为了区分DataGrid的Column属性，它的列都叫Field了，真不知道万一还有新的需要，3.0中会叫什么？

    DetailsView：如果做一个数据表的维护，那么就会有这样的东西，无聊地编写增加和个性的页面，并且写一大堆更无聊的代码。那么现在DetailsView就是其中的一个不错的解决方案了。终于解放了啊。DetailsView就是一条记录的数据控件，可以增加和修改，还可以翻页。

    FormView：可以把它当作DetailsView的自定义版本了，在下面的绑定中介绍。   

 二、Data Source Controls

    SqlDataSource：儿童玩具型数据源，它就像你平常做的数据访问类一样，不过只需要设置它的一些属性就可以工作了，并且它和其它的数据显示控件很好的合作。因此还是很方便的。如果有了VS还不懂用这个玩意儿，那么可以直接去幼儿园进修了。

    ObjectDataSource：企业级解决方案，不用再为UI层烦恼了，如果你做基于数据库的应用。可以轻松地把您的数据访问层或者业务层绑定在这个可爱的东西上面了。它用起来就像上面的儿童玩具一样的方便。真是玛丽顾得啊。  

    还有XmlDataSource和SiteMapDataSource来绑定于XML文件或站点地图（后面会提到，默认也是XML格式的），还可以使用XPath从中选择，或者直接使用XSLT转换XML（XmlDataSource）

    忘记了还有另一个儿童玩具AcceseDataSource。    

三、Data Controls Parameter

    就是上面那些Data Source的参数，有多种，就不一一解释了，仅将其列出。其中如果Data Source和Data Bound Controls共同使用时，参数名是有限制的。Parameter（静态）；QueryStringParameter；ControlParameter；SessionParameter；FormParameter；CookieParameter；ProfileParameter。

四、Improved Data Binding Syntax

    新的绑定方法<%# 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下。写法和.aspx文件基本上是一样的，只不过没有Id属性，却多了一个SkinId的属性。不用怀疑，在页面中使用同样的SkinId就可以使用这个皮肤定义的样式了。而在皮肤文件中没有使用SkinId属性的控件，将是默认应用到页面中所有没有指定SkinId的同类控件上。