我在网络上看到了很多博客、文章和讨论，这些使我相信自定义内容类型是 SharePoint 网站中必须使用的功能 - 特别是在涉及 SharePoint/MOSS 网站的无代码自定义的情况下。
然而，经过几个小时对该主题的定向研究后，内容类型（用于列表，而不是文档库）的使用对我来说似乎并不那么令人印象深刻：
- （1）我可以对类似类型的记录进行分组（例如任务）和里程碑），并为列表中的每种记录分配一组自定义字段（以及这些字段中的不同选择）。
- 例如，任务内容类型可能具有“分配给”字段和状态字段，其选项包括“未开始、进行中、完成、放弃”；里程碑内容类型可以跳过“分配给”字段，并提供状态字段，其选项为“未完成、已完成、已放弃”。
- 但是，为什么不创建单独的列表呢？将不同内容类型分组到一个列表中的原因之一是，您可以创建一个工作流程并让它处理该列表中的所有内容类型。如果您有两个单独的列表，则必须创建工作流程两次，并在两个地方维护任何更新——这真是太痛苦了。
- (2) 当我为每种内容类型设置不同的字段集时，SharePoint 将自动为每个内容类型生成不同的“新项目”和“编辑项目”表单 - 仅显示/请求与一种或另一种内容类型实际相关的字段。
- 例如，当我创建一个新的任务项时，SharePoint 创建的输入表单会自动包含“分配给”字段；当我创建新的里程碑项目时，SharePoint 创建的输入表单不包含“分配给”字段，从而使用户更容易（并保持数据更清晰）。
- (3) 每个内容类型的工作流程 – 虽然工作流程只能与一个列表关联，但您也可以将工作流程与内容类型关联。这为您提供了两个机会： 使用
- 适合每种内容类型的不同操作和条件创建不同的工作流程。
- 创建对单一内容类型进行操作的单一工作流程，并在多个列表中使用该内容类型。 （然后，以某种看待事物的方式，您会得到“多个列表中的相同工作流程”。）
- (4) 我可以在列表中创建某种类型的记录，然后配置事物，以便该“类型”的所有记录是只读的（即创建后无法编辑）。
- (5) 过滤查找： http://www.sharepointblogs.com/mossms/archive/2009/07/23/filtered-lookups-across-content-types.aspx
我错过了什么吗？列表中是否存在一些我没有看到的自定义内容类型的使用场景，这使得它们成为您必须使用的 SharePoint 功能？
I've seen a lot of blogs, articles and discussions across the web that lead me to believe that custom Content Types are must-use functionality in a SharePoint site - especially where no-code customization of SharePoint/MOSS sites are concerned.
However, after a few hours of directed research on the subject, the uses of Content Types (for Lists, not for Document Libraries) don't seem all that impressive to me:
- (1) I can group similar kinds of records (e.g. Tasks and Milestones) in the same List, and assign a custom set of fields (and different choices in those fields) to each kind of record in the List.
- e.g. a Task content type might have “Assigned To” field and a Status field whose choices include “Not Started, In Progress, Done, Waived”; the Milestone content type could skip the “Assigned To” field, and provide a Status field whose choices are “Incomplete, Completed, Waived”.
- However, why not just create separate Lists? One reason to group different Content Types in one List is so that you can create one Workflow and have it process all Content Types in that List. If you had two separate Lists, you’d have to create the Workflow twice, and maintain any updates in two places – big pain in the butt.
- (2) When I have different sets of fields for each Content Type, SharePoint will automatically generate different “New Item” and “Edit Item” forms for each – only showing/requesting the fields that are actually relevant to one content type or another.
- e.g. When I create a new Task item, the input form created by SharePoint automatically includes the “Assigned To” field; when I create a new Milestone item, the input form SharePoint creates does not include the “Assigned To” field, thus making it easier for users (and keeping the data cleaner).
- (3) Workflows per Content Type – while workflows can only be associated with one List, you can also associate a workflow to a Content Type. This gives you two opportunities:
- Create a different workflow with different Actions and Conditions that are appropriate for each Content Type.
- Create a single Workflow that operates on a single Content Type, and use that Content Type in more than one List. (Then you get “same workflow in multiple Lists”, in a certain way of looking at things.)
- (4) I can create a certain type of record in a List, and then configure things so that all records of that “type” are Read-only (i.e. cannot be edited after they’re created).
- (5) Filtered Lookups: http://www.sharepointblogs.com/mossms/archive/2009/07/23/filtered-lookups-across-content-types.aspx
Am I missing something? Is there some usage scenario for custom Content Types in Lists that I'm not seeing, and that makes them a must-use feature of SharePoint for you?
发布评论
评论（3）
贾尼斯和亚历克斯提出的观点都很好。以下是我自己的一些想法：
Janis 提出的“阶级”类比是一个很好的类比。内容类型不仅仅是数据——它们是与该数据相关的行为。这种“行为可移植性”使我们不再将 SharePoint 数据简单地放在列表中。受列表限制尤其受到限制；内容类型打破了这一限制。
内容类型本质上是分层的并且支持继承（正如 Janis 所提到的）。您可以根据需要创建任意复杂的层次结构，就像类层次结构一样。层次结构中较深的内容类型从继承链中较高的位置继承字段和大多数与代码相关的元素。您可以选择在派生类型中保留父行为或覆盖它。
我特别喜欢内容类型（与行为可移植性相关）的一点是能够指定用于查看和处理数据的自定义表单。我不是在谈论插入列表表单页面的FormTemplates；我说的是一种亲手打造的体验。通过精心设计的表单（通过在内容类型的 XmlDocument 结构中指定的 FormUrl 元素绑定），SharePoint 的整个“以列表为中心”的思维方式可以被彻底颠覆。如果您需要，空白的 ASPX 页面将成为您的画布。
归根结底，我想这可以归结为这一点（对我来说）：我可以考虑将数据绑定到列表以及该列表的行为，或者我可以考虑数据本质上与内容类型更像 OOP 。 Microsoft 在 SharePoint 平台内的内容类型方面进行了大量投资，并且他们为在任何网站的信息体系结构中使用这些内容类型提供了强有力的论据。选择不使用它们可能会在未来产生一些惊喜。
这里仅举一个例子：MOSS 记录中心。 MOSS 记录中心的“核心”利用内容类型作为路由和排序机制来简化生活 (http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx）。如果您有大量没有内容类型分类的数据，并且您选择利用记录中心......哎呀。
这是另一个例子：搜索。通过基于内容类型的明确定义的信息体系结构，分区搜索范围可以变得更加容易，因为内容类型可以几乎毫不费力地转换为托管属性。对于我当前的客户，我们这样做是为了轻松识别内容并对其进行分类，以实现自动范围包含。
极端的例子：出版网站。如果不使用内容类型，您甚至无法利用发布网站功能，因为所有发布布局都与内容类型相关联，以便将列表数据与布局占位符对齐。
我可以继续说下去，但希望这能让您了解什么内容类型可以为您作为开发人员和管理员做些什么。您当然不需要使用它们，但它们确实比 WSSv2/SPS 2003 的列表特定数据天有了很大的改进。
值得！
The points that both Janis and Alex make are good ones. Here are a few of my own:
The "class" analogy that Janis draws is a good one. Content types aren't just data -- they're the behavior that goes with that data. This "behavior portability" enables us to stop thinking of SharePoint data as simply sitting in a list. Being list-bound is particularly constraining; content types break that constraint.
Content types are hierarchical in nature and support inheritance (as Janis alluded to). You can create as complex a hierarchy as you like, much like a class hierarchy. Content types deeper in the hierachy inherit fields and most code-related elements from higher in the inheritance chain. You can choose to keep parent behavior in a derived type or override it.
Something I particularly like about content types (related to behavior portability) is the ability to specify custom forms for viewing and working with data. I'm not talking about FormTemplates which plug into list form pages; I'm talking about a craft-your-own experience. The entire "list-centric" mindset of SharePoint can be turned upside down through well-crafted forms that are tied in via FormUrl elements specified in a content type's XmlDocument structure. A blank ASPX page becomes your canvas if you want it.
At the end of the day, I guess it comes down to this (for me): I can think about data being bound to a list and that list's behavior, or I can think about data being more OOP-like in nature with content types. Microsoft has made a heavy investment in content types within the SharePoint platform, and they've made strong arguments for their use in the information architecture of any site. Choosing not to use them could yield some surprises down the road.
Here's one just as an example: the MOSS Records Center. The "guts" of the MOSS Records Center leverages content types as a routing and sorting mechanism to simplify life (http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx). If you've got a lot of data without content type classifications and you elect to leverage a Records Center ... ouch.
Here's another example: search. With a well-defined information architecture based on content types, partitioning search scopes can become much easier since content type can be converted to a managed property almost effortlessly. With my current client, we do this to easily identify and categorize content for automatic scope inclusion.
Extreme example: publishing sites. You can't even leverage publishing site features without the use of content types, because all publishing layouts are tied to a content type in order to align list data with layout placeholders.
I could go on, but hopefully this gives you an idea of what content types can do for you both as both a developer and an admin. You certainly don't need to use them, but they do represent quite an improvement over the list-specific data days of WSSv2/SPS 2003.
For what it's worth!
我将它们视为班级。为什么不对数据进行分类？
例如，您可以附加 上下文菜单项 或 事件侦听器 或工作流到内容类型。或者，如果您需要其他字段，只需将其添加到内容类型中，它就会在使用数据的任何地方添加它。
I see them as classes. Why not classify your data?
For example you can attach context menu items or event listeners or workflows to a content type. Or if it turns out you need another fields, just add it to content type and it adds it everywhere data is used.
它们之所以成为我必须使用的功能，是因为我经常在站点的许多位置部署相同的列表。要更改列表列，我只需更改父内容类型，然后使用该内容类型的所有列表都会更新。
但也作为 Janis 说这是关于对数据进行分类。仔细考虑数据结构并在内容类型中定义它。然后可以将该内容类型部署在任何需要的地方，并且始终集中更新。这使得数据结构的管理一致、可预测和可重复。
这也是一个好兆头，表明解决方案的开发者对规划业务需求以及将业务需求与产品相匹配给予了一定的关注。否则，它可能表明存在创建临时列表的倾向，这通常会成为维护的噩梦。
The reason why they are a must-use feature for me is because I often have the same list deployed in many locations across a site. To make a change to the list columns I can just change the parent content type and all of the lists using that content type are updated.
But also as Janis says it's about classifying your data. Think through the data structure and define it in a content type. That content type can then be deployed wherever required and always updated centrally. This makes management of the data structure consistent, predictable and repeatable.
It's also a good sign that whoever developed the solution paid some attention to planning and matching business requirements with the product. Otherwise it can indicate there has been a tendency to create lists ad hoc which can often end up being a maintenance nightmare.