You’ve seen how content types are used throughout SharePoint to determine how specific types of data should be handled. We’ve looked at the types of metadata that can be stored within a content type. One of the areas that we haven’t discussed so far is how individual items of data are defined, and that’s where columns come in. Every content type contains a reference to one or more column objects, where a column defines a specific data element together with any appropriate metadata required to capture, process, and render it. Columns can be reused in multiple content types, and in fact this reuse is central to the way content type inheritance is implemented. For example, suppose the Item content type references a column named Title. As a result, all content types that inherit from Item also contain a reference to this Title column. Columns, like content types, are available across child sites. Where the columns are used in a content type that is published using content type publishing, the columns are available across site collections.
One of the most important properties of a column is the type of data that it can contain. A number of built-in options are available, and a full list can be obtained by examining the SPFieldType enumeration in the Microsoft. Share Point name space. Some of the commonly used types include the following:
LookupSpecifies that the column contains a reference to a value in another list The following code sample shows how to create columns and associate them with content types:
As you’ve seen, the SPFieldType enumeration can be used to determine the type of data that a column can contain. However, it’s possible to create custom field types that inherit from these base types and in turn use those custom field types to create columns.
There’s more to field types than simply specifying the type of data that a field can contain. Let’s take a look at the objects involved before we delve into how they interact to provide data access services for SharePoint. The following diagram shows the key objects involved in creating custom field types.
Inheriting from SPField
The SPField class is the base class for all field types. Some examples of these field types include SPFieldFile, which contains file data, and SPFieldLookup, which contains details of a lookup to a column in another list or library. All field types must ultimately derive from SPField either directly or indirectly. From a data access perspective, the SPField class is the lowest level at which we can implement custom data access code, since behind the scenes of the SPField class, the SharePoint platform handles the appropriate database interactions to persist the value of the object.
As of this writing, Visual Studio 2010 does not provide a template for creating custom field controls, so let’s take a look at how this can be done manually.
Our sample field will store multiple values in a single field. Rather than write a lot of the code to implement this functionality from scratch, we’ve based our field on SPFieldMultiColumn as opposed to SPField. SPFieldMultiColumn stores values of type SPFieldMultiColumnValue, and by inheriting from this class, we can create a custom data structure for our field.
Inheriting from BaseFieldControl
The SPField class has many properties that define how a column based on the field type will behave. One of these properties, FieldRenderingControl leads us onto the BaseFieldControl class.
Each SPField-derived class must implement the FieldRenderingControl property, which will return an object of type BaseFieldControl. Notice, however, that BaseFieldControl is an abstract class. This means that in practice, each SPField derived class must return a concrete implementation of the BaseFieldControl. Some examples of these implementations include LookupField and FileField. These FieldRenderingControls are responsible for defining and implementing the user interface for each field type. For example, in the case of the Lookup Field control, when the page is in edit mode, the user interface may consist of a drop down control containing values from the configured lookup list. In the same way as the SPField object represents the lowest level of data access code, the BaseFieldControl represents the lowest level of user interface code that can be written against the SharePoint platform. Continuing with our earlier SPField example, we’ll add a custom field control to provide us with a user interface for capturing data.
To hook up our custom BaseFieldControl to our SPField implementation, add the following code to the SPFieldAddress.cs class:
In SharePoint 2007, adding validation to fields was one of the main reasons for creating a custom field control. As you’ve seen, creating field controls is a time-consuming task. The good people at Microsoft realized that, from a development perspective, this wasn’t a good use of resources and as a result, in SharePoint 2010, column validation has been added to the SPField class. In effect, column validation eliminates the need for a lot of custom field development by making it possible to enter validation formulae via the user interface. When you’re adding a new column, you’ll see a new Column Validation section at the bottom of the page, as shown next. Validation formulae use the same syntax as calculated columns and as such can include pretty complex logic.
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.