The aim of the SharePoint data access platform, and indeed of SharePoint itself, is to provide a web-based tool that can be easily customized by end users to store any business data, either in raw database-style by using custom lists or embedded in documents by using document libraries and features such as Excel Services. At the fundamental level, both of these approaches have a common implementation in the form of content types. Basically, a content type is a metadata definition of a particular type of content.
Content Type Inheritance
One important feature of content types is inheritance. In SharePoint, all content types inherit properties from the System content type, and when users create new content types, they must select an appropriate parent content type from which to inherit. You can see from the hierarchy shown in Figure that custom list data can be stored by creating a content type that inherits from the Item content type whereas documents can be stored by using the appropriate Document content type or by creating a new content type that inherits from Document.
Content Type Identifiers
One thing that may be apparent from Figure is the use of concatenated unique identifiers for each content type. For example, the identifier for the Master Page content is type is 0x010105, which is shown in Figure 13-2.
Although from a development perspective, the use of concatenated identifiers may seem a bit archaic and prone to data entry errors, there is a very good reason for taking this approach as opposed to the more traditional technique of assigning automatically generated sequential identifiers. Practically all of the functionality of the SharePoint platform is defined at the content type level. For example, a web page containing web parts is based on the Web Part Page content type. It is the use of this content type that provides the necessary data structure required to store the properties of the web parts that are stored on the page.
However, the Web Part Page content type is also based on the Basic Page content type, and it is via this inheritance that a physical representation of the page can be rendered from the database.
The System content type hierarchy in SharePoint 2010
Breakdown of content type identifier for Master Page content type
Since functionality is effectively layered based on the content type hierarchy, being able to navigate up and down the structure efficiently is key to the overall performance of the system. By using concatenated identifiers, system code can easily derive the hierarchy without having to resort to database lookups or other methods.
Generating Content Type Identifiers
When programmatically creating content types, you can use two approaches to generating content type identifiers. The first approach, which is used by out-of-the-box content types, is to use this:
Parent content type ID + 2 hexadecimal digits (other than 00, because this is reserved for use by the second method)
For example, if we wanted to create a new content type derived from Master Page, we could use the following identifier:
The second approach, which is recommended when creating a content type that inherits from a parent that you didn’t create, is to use this:
Parent content type ID + 00 + hexadecimal GUID
Using the preceding example of a content type derived from Master Page, we could use the following identifier:
The SPContentTypeId Object To make parsing of content type identifiers easier in code, the SharePoint object modelincludes the SPContentTypeId class. The SPContentTypeId class makes it easy to performvarious actions against content types, such as determining the parent content type identifieror finding a common parent of two identifiers.
The following code listing shows how to create a content type programmatically with a user-defined identifier as well as with a system-defined identifier. You can see that systemdefined identifiers always adopt the lengthier GUID concatenation approach.
Geerally speaking, performing such actions using code would be required only as part of the initial setup of a site or site collection.
Content Type Groups
Although all content types are fundamentally derived from the System content type and exist as part of a well-defined hierarchy, for ease of reference, content types can also be grouped. Grouping is purely a metadata activity and has no bearing on content type inheritance. That said, some groups serve specific purposes within the SharePoint platform, and one example is the _Hidden group. Content types belonging to this group are not displayed in the user interface. Another thing to bear in mind when using content types is the way in which folders and content hierarchy are implemented. When creating a document library, you cannot add content types that are not derived from Document. By the same token, when you’re creating a custom list, you cannot add content types that are derived from Document. Notwithstanding these rules, lists and document libraries can contain content conforming to many different content types. For example, a document library can contain Master Pages and Web Part Pages.
Content Type Metadata
You’ve seen how content types are organized into a hierarchy and how inheritance determines the functionality that is enabled by a given content type. Now let’s take a look at the type of metadata, and therefore the types of functionality, that can be exposed by content types.
Workflows can be associated with content types and set to run in response to certain events. By attaching workflows to content types rather than individual lists, you can define business processes for specific types of data regardless of where the data is stored within a SharePoint site.
For some types of content, particularly those based on Microsoft Office documents such as Word or Excel docs, custom templates can be specified that users can populate with relevant details. Details of such a template can be specified as content type metadata, allowing the template to be used wherever the content type is added to a document library.
Display, Edit, and New Forms
Each content type can define custom display, edit, and new forms allowing customization of the user interface presented at these stages. Various options are available for customizing these forms; however, from a content type perspective, it’s important to note that two properties exist for each form. For example, to set the Display form, you can use a Display Form Template Name property and a DisplayFormUrl property. Which property you use depends on the level of customization that’s required. By setting the DisplayFormTemplateName property, you can specify a template that will be used by the DataForm Web part to render the appropriate view. However, if a greater level of customization is required, the Display Form Url can be set to the URL for a custom Active Server Page Framework (ASPX) page, allowing a much greater degree of flexibility with the draw back that none of the usual SharePoint user interface elements will be present on the page by default.
Mobile Display, Edit, New Pages
SharePoint 2010 provides a number of new features for rendering content for mobile browsers. One example of this new functionality is the ability to specify custom forms for creating and editing content using mobile browsers at the content type level.
The ability to add practically any XML-based metadata to a content type is an incredibly powerful feature. Interestingly, some of the metadata already described, although accessible through the object model via dedicated properties, is actually attached to a content type via additional XML documents.
The following code sample shows how metadata can be added by creating a custom class that supports XML serialization and then setting properties on the class to contain the appropriate values. Using this technique, you can attach practically any additional data to a content type.
Enterprise Content Type
Earlier in this book, site collections and sites and the hierarchical nature of these structures were discussed. This hierarchy also has implications for content types, because content types are also inherited by child sites. For example, if an organization creates a site collection named HR with a root site of Benefits, a content type named Employee defined on the Benefits site would be available to all child sites, no matter where they sat within the hierarchy, as shown next:
This cross-site scoping is an important feature in SharePoint, because it facilitates the creation of centrally managed data structures. However, while this inheritance works well within site collections, it doesn’t work across site collections. From the preceding illustration, if another site collection named Training existed with a root site of LearningCenter that also wanted to make use of a common Employee content type, using previous versions of SharePoint it would be necessary to create a new content type on the LearningCenter site.SharePoint Server 2010 introduces a new feature known as enterprise content types, and it’s aimed at providing an answer to this problem. To enable content type publishing, take the following steps:
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.