【IT168 技术文档】这次TechEd我和老侯讲的Session，在MVP Community Cabana，和其他几个同等类型的session相比起来听众不多

  把大致内容和demo的截图总结一下，算个记录，也给没机会去TechEd的留个东西，另外给我们的一些组件做个广告

  言归正传，这个Session的表面上的主要内容是应用WSS构建数据跟踪（Data Tracking）类型的协作应用平台，实际上是通过自定义字段类型来拼装SharePoint应用。首先这个应用平台的两个限定词先解释一下：

  1、数据跟踪类型的应用，其实按理说应该是叫数据流类型的。基本上就是以数据流转为主的协作应用，比如场地预订、图书借阅之类的

  2、协作型应用，也就是说是由一组人或一些角色来共同完成的应用。比如小组、部门或企业内部的。

  微软将应用平台按照类型划分为大概如下几种：Lists（由简单数据表构建的数据存储）、Tracking application（数据跟踪类型）、Mini LOB application（简单的小型业务系统）、LOB(Line of business) application（企业核心业务系统）。按照其应用的数量（横轴）和构建复杂度（纵轴），微软给出了这样一张图：

  数据列表类型的应用虽然构建简单，但占据了大量的数量（例如联系人、通知、讨论、简单的文档共享灯）；企业核心的业务系统虽然构建复杂，但应用的数量相对非常少。

  先来看看一个应用的组成部分，以及SharePoint在这些部分中的优缺点：

  （1）数据结构定义。SharePoint的列表是一个很好的容器，虽然其存储能力有限，但一般来说足够满足一些日常的应用。而且SharePoint列表也如同数据表一样，内置了多种数据类型，并且包含了一些构建应用基本的“应用字段类型”，例如超链接、选项、查阅项等。

  （2）视图。SharePoint内置的列表视图功能比较完善，支持数据列的选择、筛选、排序、最大两级的分组等等。不过SharePoint视图没有权限，难以通过视图控制不同角色的查看。

  （3）表单。SharePoint列表创建出来之后，会自动生成3个相应的表单：查看、新建和编辑。但是表单的样式、字段的样式都是固定的，即使通过SPD，能够做出的修改也非常有限，难以适应用户多样的需求。

  （4）权限管理。SharePoint在发展到WSSv3之后支持到条目级别的权限。但是不支持字段级别的权限，这对于应用来说比较麻烦，难以控制某些字段哪些人可见、哪些人可以编辑。

  （5）业务逻辑。SharePoint列表只是一个容器，应用的逻辑一般都需要开发或配置来完成。好在列表的工具栏、下拉菜单都提供了方便的扩展特性，可以加入一些自定义的操作。事件处理程序、工作流也可以在一定程度上满足对条目在逻辑方便的控制。

  WSS作为一个以协作为主要目的平台，经常被用于进行文档管理、知识管理、简单的内容共享的应用（也就是对应Lists类型的应用）；而且大多数用户都希望SharePoint能够方便的完成复杂一些的协作型应用（也就是图中第二个层次的应用，也是这次session的主要议题）。然而在使用中，我们会发现SharePoint虽然提供了很多方便的特性，但在某些关键方面难以满足我们的需求，无法通过内置功能的拼装达到我们的目的，需要进行二次开发。而这个session的主要目的，就是通过一些开发好的自定义字段类型组件，来方便、快速地拼装出实际的协同应用平台。

自定义字段类型我就不再过多地介绍了，这是WSSv3新加入的特性，极大地扩展了对列表的开发余地。通过自定义字段类型，可以根本地解决表单多样性的问题、从一定程度上解决字段级权限控制和业务逻辑的辅助。

后面就是通过我们一些已有的自定义字段类型，来完成一些特定的功能，最后给出一个由自定义字段类型拼装完整应用的例子。