从这一节开始正式涉及到自定义字段类型的内容，嗯……不过这次还是没有代码

   本次主要介绍一下自定义列表字段类型的大致内容，用途和缺点，以及大概的体系

   上一次说到了SharePoint本身内置了很多种字段类型（其实还有更多，只不过我们没办法自己用罢了，都是系统默认的，比如Counter、File之类），这些字段类型虽然已经比2003时代要丰富而且功能强大了很多，但是有时依然不能满足我们的需求。例如如果你想做一个Email地址栏，你当然可以选择使用单行文本，但是一个好的Email地址输入是可以进行合法性验证的，单行文本却不行；又比如你想做更强大的输入界面，比如评分（现在SharePoint中已经有一个类似的东西了，RatingScale，但是遗憾地它只能用在调查列表中），你希望能把它做成youtube那样的效果；再比如你要做一个能够带有自动判重功能的输入栏……

   自定义字段类型是一个很能激发我们想像力的东西，比如我们可以把一个字段类型当做一个按钮，它本身可以不存任何数据，只是在输入界面中根据其它字段来判断一些东西（比如我有两个时间类型的字段分别存放会议开始时间和结束时间，然后我可以做这么一个“按钮”字段，以便在输入的时候就可以判断有没有与此冲突的会议时间——这往往比使用Event Handler更加人性化一些，因为那是在提交后才判断的）。最近越来越发现自定义字段的强大，甚至有一种机制可以让不同字段之间进行交互，今天侯同学刚发现的这一点，大概试了试原理，还没用到字段类型上，等试出来了再说。

   好了，言归正传，自定义字段类型主要解决的是以下问题：

   更复杂的输入、显示界面
   自定义的合法性判断检测
  更复杂的逻辑
  其他一些默认字段所无法完成的功能
  举一些例子：

   地址。我们在网上购物的过程中填写地址时，经常会发现它分成了几个不同的部分让我们输入，比如省、市、区、街道、邮编等等。那么如果使用SharePoint默认功能的话，我们只能把这些分别存在一些栏中，这显然不好。自定义列表字段就可以把它们存在一个栏中，但是可以分别输入各个部分。（事实上，Todd的USAddress这个字段类型也是我见过的第一个自定义字段类型） 
   Email地址。如上所述，可以使用正则表达式加上一些合法性验证。 
   评分。更加人性化的输入和输出，让用户使用时不在是只和枯燥的数字打交道。
   外部数据查阅。虽然默认有了BDC查阅和查阅项，但是有时我们可能会需要更灵活些的查阅，比如跨网站查阅列表内容（还记得么？这是2007支持的功能！但是并没有体现在默认界面上罢了）
   当然，自定义字段类型并不是功能较多的，它有着这样那样的局限，而且其中很多都非常诡异：

   首先，自定义列表字段是不被office系列的客户端支持的。也就是说，我们觉得很好用的那个“文档信息面板”是不支持自定义字段类型的。我们在文档库中添加一个自定义列表字段时，甚至都会出现这样的提示：



如果你不记得什么是“文档信息面板”的话，（在线创建一篇文档时）：



    其次，非常奇怪的，自定义字段类型中的值不能超过255个字符（即使你继承了多行文本也不行！），就“好像”它们都是从单行文本衍生出来似的（我们知道单行文本的最大长度就是255）。这是一个老外发现的，非常没道理的一个限制，那个老外最后用的方法是继承了多选这种字段类型，这样就可以多放几个255字符了，虽然选项数也是有限制的……

    另外，现在的自定义字段类型有一个很严重的bug，就是按照标准的编程方法（我指的是SDK里写的方法），它无法保存自定义的属性（每个字段类型都有些独特的属性，比如数值型中的最大值、最小值）。当然，这并不意味着我们就不能保存自定义属性，有一些解决方案去使用它（其中一种阳春白雪，从SharePoint存储自定义属性的原理入手，但是这个改起来超级麻烦；另外一种是我发明的，虽然看起来很丑陋，但事实证明有效且简单），我在后面会讲到具体怎么做。

    最后，我们开发人员最关注的就是，这个东西开发起来比较繁琐，尤其当你有很多需求要加进去时。虽然它并没有workflow那么深奥，但由于涉及到的东西比较多，所以还是有点难度的。还是Web部件和Event Handler容易啊……感叹一下。每次我讲自定义列表字段开发的时候，虽然我已经尽量把它涉及到的原理讲清楚了，但台下的反响还是云里雾里……不自己亲自做几个的话，恐怕是很难深入理解的。