之后，通过一个完整的会场预订的应用，展示了如何通过自定义字段类型，来快速地拼装这种协作型的应用：

  首先，一个会场预订的功能必然会有一个会场的列表。使用一个自定义列表来创建会场列表，包含了会场的标题、所在区、所在酒店和一些相关信息。

  1、在很多地点相关或者类型相关的字段中，我们往往能够希望两个甚至多个下拉列表框能够互动，比如说当选择“北京”后，列出北京的区域；选择天津后，列出天津的区域。这可以通过一个自定义字段类型来完成，相关联的父字段、关联的内容都可以灵活定义：

  2、作为相关内容，一个场地肯定会有多条相关内容。这也是在应用构建中非常常见的一种主-子表类型的表关联，通过一个外键进行关联。在SharePoint中，查阅项的作用与此非常类似，可以在子表中设置一个指向主表的查阅项（外键）。然而这种查阅项有时是非常不直观的，只能在子表中看到其条目属于哪个主表，难以看到主表条目中有哪些相关的内容。通过一个“反向查阅项”（或者主-子表字段）类型，就可以实现这一功能。设置可以在主表的编辑页面中，直接新建、修改、删除相关的子表字段：

  实际上这个相关内容是保存在另一个列表中，有一个指向“场地列表”的查阅项。主表编辑页面中的新建、编辑页面直接使用了子表的新建和编辑页面，只不过做了一些小的修改（在表单打开时自动初始化查阅项指向对应的主表条目）。

  3、预订场地通过另外一个列表来实现，可以直接进入这个列表新建列表条目，然而更直接也更友好的方式，就是直接在场地列表中对“心仪”的场地进行预订操作（在列表界面和条目界面都可以进行操作，直接转入场地预订列表的新建页面）：

  4、场地预订列表中为了标示预订的场地，会设置一个查阅项指向场地列表。但如果出于某种考虑，希望讲场地列表和场地预订列表放在不同的网站上（例如场地列表在资源网站上，由资源管理者统一管理；而场地预订列表在会议网站中），就需要借助另一个自定义字段，跨网站查阅项。这个自定义字段和查阅项的功能基本相同，只是SharePoint内置查阅项只能查阅同一网站中的列表，而这个可以跨网站查阅，并且可以指定一个视图做初次筛选（以免查阅项中出现的内容过多难以选取）。（其实跨网站查阅这一功能在SharePoint查阅项中是提供了的，只不过没有开放到界面上）。它的设置界面：

  5、所有资源预订类的应用都必然有一个需求，那就是冲突检测。一般的做法是将冲突检测放在事件处理程序中，如果有冲突则抛出异常，不过这不够方便，如果能够在填写场地、时间的时候就能实时地检查是否有冲突，那是最好不过了：

  这是一个挑战想象力、颠覆传统的自定义字段类型，按照惯常的思维方式，列表的字段一定是作为某一种特定的数据存储之用的；然而，这个“时间冲突检测”的自定义字段类型，不保存任何数据，仅是在新建和编辑页面上出现，提供一个操作。

  好了，现在我们可以看到这些场地预订的情况了，日历视图能够让显示更加直观：

  6、最后，一个预订系统必然要有的一项就是管理员的审批操作。“好，这个地方这段时间就归你了。”/“不行，这个地方要留作它用。”管理员的选择无非就是这两种。当预订较少的时候，管理员可以直接通过SharePoint的审批视图依次查看每个条目进行审批；但一旦条目多起来，偷懒的管理员（懒是世界进步的动力，嗯嗯）希望能够一次性审批多个条目。“要是能像邮箱那样给个多选框，让我选中要批准的，再一点鼠标，就全部搞定该多好。”于是又一个自定义字段登场，它同样只作用于展示层，不保存任何数据：

  配合这个自定义操作，管理员就可以有更多的时间来……咳咳。

  至此，一个完整的会场预订功能就拼装出来了。尽管它有一些简单，但是基本上包含了一个数据流转的协作型应用的所有步骤了。而且在这个应用拼装的过程中，除了最后为真正完成多项审批而编写的10行左右代码，整个过程中几乎没有任何代码操作，完全通过自定义字段类型和其他一些webpart的配置就达到了目的。这极大地方便了管理员的操作，于是IT Pro们就有更多的时间用来聊天灌水了（这不是我，嗯，我不是IT Pro，嘿，说你呢……）。

  当然，最后这个应用里有一些小trick，比如如何改变列表条目的下拉菜单、如何改变工具栏菜单。当然，你说可以通过feature来做，但是这个demo中的这些菜单没有一个是通过feature完成的。为什么？因为feature只能挂在某中列表类型或者内容类型上，麻烦……至于是怎么做的，等今后有时间再慢慢介绍。