ASP.NET 3.5 的 ListView 控件与 CSS Friendly

之前在写CSS有关文章的时候，我就想写写如何使用ASP.NET控件能够更加CSS Friendly，更容易实现一些常见的页面布局pattern，然而之后就发现这并非那么容易的。说起来要让ASP.NET控简变得CSS Friendly很容易，直接使用ASP.NET 2.0 CSS Friendly Control Adapters就是了，然而事实并非如此简单。

CSS Friendly Control Adapters的不足

首先请允许我对这个CSS Friendly Control Adapters抱怨一下。我第一眼看到它输出的class名称我就觉得很faint了，举一些例子：AspNet-Menu、AspNet-Menu-WithChildren、AspNet-Menu-Leaf。如果你习惯了客户端代码一律使用camel命名法的话，你看到这样的命名就会觉得无法适从，你是要改变原有的命名法来迁就这些控件呢，还是让多种命名法在你的CSS文件中混排呢。如果需要改变这些默认的class命名呢？不好意思，控件自身的CssClass属性已经没有任何作用，因为控件输出的HTML结构都改变了，那些CssClass也就不再对应哪个HTML元素了。因此，如果你需要改变这些class命名，唯一的办法就是直接更改ControlAdapter的源代码，而class命名是以字符串形式硬编码在源代码中的，就算你用搜索替换你还是会害怕替换多了或者替换少了从而引入了更多的麻烦。

说到源代码，这些ControlAdapter的第二个麻烦也就浮现了——网站必须携带它们的所有源代码，而不仅仅是编译好的dll，而且这些源代码的可修改性并不强。为什么说可修改性不强？如果你有想过自己写一些ControlAdapter的哈，我想你已经参考过现有的那几个ControlAdapter了，你会发现编写ControlAdapter严重依赖于你对该Control本身的理解，不仅仅是对Control公开部分的了解，还需要对Control内在逻辑的深入理解。因此，要么你是Control的作者本身，要么你就细看过Control的源代码，否则不可能写出ControlAdapter，甚至修改已有的都很难。

因此，CSS Friendly Control Adapters是一个非常之鸡肋的选择，我们不如向前看，看看Microsoft在ASP.NET 3.5中为我们提供了什么。

ListView以及全新的TemplateControl形式

ListView是ASP.NET 3.5新引入的一个控件，如果你还没有使用上Orcas，或者没试用过这个控件，那么不妨看看ScottGu的介绍性文章：The asp:ListView control。这篇文章详细说明了如何先设计一个原型页，然后设计LINQ to SQL以便获取数据，在将数据绑定到ListView上面，最后还加上DataPager分页。我们不需要看那么多，看ListView那部分就是了，看看声明ListView的代码。

如果你熟悉之前Atlas提供的Sys.UI.Data.ListView，那么你一定会觉得这两个ListView很相似。与之前的TemplateControl（例如GridView）不同，ListView不再直接输出容器本身的代码，而提供了一个Template给你自定义容器，你可以在这个Template中自由编写你的容器代码，它可以是<table />，也可以是<ul />或<ol />。之后项目的Template也是允许自定义的，对应<table />的自然是<tr />，而对应<ul />与<ol />的则应该是<li />。因为这些都是你手动编写的HTML代码，所以你可以随意地给它们设置class属性，从而让你能在整个网站中保持命名风格一致性。

Web Form的屈服？

ASP进化到ASP.NET的时候，好像Win Form那样的拖放控件支持成为了最大的特色，然而现在Web Form的编写方式又变回和其它服务器端脚本语言（例如VBScript）差不多了。以前ASP的时候，不就是自己写容器的HTML咯，然后用<%For ... Next%>把项目HTML圈起来，现在改为叫做模板其实没什么差别啊，况且其他服务器端脚本语言都有类似的写法，不过可能是helper函数或者别的称呼，都差不多。

因此，事实证明除非放弃对HTML细节的控制权（而这又难以做到CSS Friendly），否则对于大多数服务器端语言来说声明数据表现模板的方式都是类似的，没有更便捷的方式了。能够省事的是数据访问方法，从ADO进化到ADO.NET，从Typed DataSet到LINQ to SQL。将来Microsoft是否会发布更多类似的TemplateControl还很难说，因为ListView已经有非常高的可定制性，原来用来表示二维表数据结构的DataControl都可以用它作为替代品，同领域的控件已经没意义了，不像以前要分开几个DataControl了。我觉得接下来最好能看到一个取代Menu的CSS Friendly Control，因为Menu所表现的数据结构不是二维表，而是树，有必要为这种数据结构提供一个能准确声明HTML细节的控件。

最后，如果你对我的blog中关于ASP.NET与CSS的文章感兴趣的话，可以考虑订阅：

• Cat in Chinese (feed）
• Cat in dotNET (feed)

买了两本 Photoshop 的书

两本都是《选择的艺术》这个系列的，其中一本是《Photoshop CS图像处理深度剖析》，另一本是《Photoshop CS图层通道深度剖析》。买Photoshop的书，是因为工作中要用到，作为一位web设计人员，单纯需要编写代码的工作暂时还不存在（虽然Microsoft的产品线设计尝试让设计师与程序员能够低耦合度合作），因此学好一些基础的设计思想与设计工具运用知识还是有必要的。

例如Google的Webmaster职位，要求就包括Adobe Photoshop操作知识。我暂时只能用Fireworks做一些简单的mockup，mockup的素材没办法自己用Photoshop处理，这就大大限制创意的发挥。另外我还想去学学摄影，因为在我还不能什么都用Photoshop画出来之前，素材的获取有时候就必须依赖于实物，看来要补的知识还真是一大堆啊。

为什么 Flixster 比豆瓣更好

虽然我主要适用豆瓣记录书、电影、音乐，然而用过Flixster之后就为它所吸引，希望豆瓣能够加上Flixter那样的功能。

在我认真使用豆瓣之前，Piggest跟我说过豆瓣的优点：在你注册并添加少量已经看过的电影后，你会发现你想继续添加的电影通常已经出现在“豆瓣猜你会喜欢”的列表上，这时候添加就方便很多了，因为无需再按名字搜索，直接点击就是了。然而Flixter更先进，它根据大家看过电影的历史分析出所谓的经典电影，也就是人人都看过的，没看过至少听说过的，在你注册后就提供这些经典电影给你评分。假如我没看过一部电影，而且也不想看，怎么办？Flixster比豆瓣多了一个“不感兴趣”的选项，这应该算是一个更体贴用户的设计，而这个设计豆瓣后来也加上了，不过不是一个直接的选项，而是你可以选择隐藏“豆瓣猜你会喜欢”列表上的推荐项目，那也相当于是不感兴趣吧。

对于一个Web2.0的网站来说，数据是很重要的，掌握的数据越多，就能越有效的服务现有用户，对新用户的吸引力也越大。在获取数据方面，Flixster的做法显然比豆瓣更好，对经典电影的评价几乎人人都有，而此时以推的形式主动要求用户评分并不会让用户觉得觉得不喜欢，反而提供了便捷，即使有用户不喜欢这样，他也可以选择之际跳过这个步骤。类似的，其实很多Web2.0网站都可以在用户注册的过程最后加上一个可选步骤，要求用户提供更多信息，而网站要设计好获取信息的方式，让用户觉得不用动脑筋就能填写，并且提醒用户在这里填写能够更便利更快得到全面的服务。

今天开始翻译 Prototype and Scriptaculous in Action

感谢Dflying Chen的联系与推荐，让我有机会为图灵公司翻译Prototype and Scriptaculous in Action的简体中文版。这本书的作者包括Ajax in Action的作者Dave Crane，同时作为引进大陆的首本关于Prototype的书，因此估计将会热卖。

基于上述因素，翻译此书时我必须特别小心，避免任何翻译错误甚至仅仅是可能引起争议的地方，因为一旦这书上市了必定有不少读过英文版的人来读中文版，接着就可能指出他们认为翻译得不够好的地方，即使那个地方是纯粹文学性的并且与书中讨论的技术细节没任何联系。现在是Web2.0时代，你犯的任何错误都将被别人永久的记录在Internet上，如果第一本翻译的书出问题了那么将来就很难再被信任以担任同类工作，因为读者认为你的翻译不好的话出版社就敢让你翻译。实际上不仅仅翻译工作如此，现在的Internet逼着你我以及任何一个人做事时都必须加倍小心，面对公众所犯下的错误都将被一大堆人记录到他们的blog上，这种负面影响难以用你的个人之力以消除。当然，事情也有好的一面的，如果翻译做好了将能得到相当的赞誉，这种来自公众的赞誉也不是别人轻易能够克隆的，因此也有相当的含金量。

最后，如果你希望对我的翻译工作提供任何的建议或支持，或者你有兴趣和我合作翻译，欢迎留言或联系我。直接在blog回复留下联系方式的话，我将会主动联系你。