A.5. Building a Custom Content Type Using VSeWSS

The content type that the policy management site will use will have several custom fields defined that will appear in the available site columns' page after they are provisioned (see below table). Each of the fields that is being created will be referenced by the content type in the <FieldRefs> node (See Listing A-6) by using the ID and Name that is provided within the <Field> element of in Policies.Field.xml (see Listing A-7). When you define the content type using VSeWSS, it will generate the contenttype.xml and the contentype.fields.xml file, already providing a sample field element that can be used as a boilerplate for further field integration.

The following code defines the policy library content type with the ancestral attribute of the content type (0x0101, in this case, specifying a document library), the content type description attributes, the content type references to the three custom fields as defined by the Policies.Field.xml (see Listing A-7), and associated SharePoint listform pages for interacting with the policy library (see Listing A-6).

Example A.6. Policies.xml (policies content type)

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!--document library ancestral type 0x0101-->
  <ContentType  ID="0x0101005681071F88374fe0BFD45E7C0340C528"
        Name="PolicyLib"
        Group="Policy Content Type"
        Description="Documents for product"
        Version="0">
    <FieldRefs>
      <!--Policy ID-->
      <FieldRef ID="{78953994-21C2-4737-A7FA-E7FC6019CA74}" Name="PolicyID"
Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE"/>
      <!--Policy Name-->
      <FieldRef ID="{358E48C9-D527-4718-BA6F-438A6A12922A}" Name="PolicyName"
Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE"/>
      <!--Effective Policy Date-->
      <FieldRef ID="{3FB081E8-C903-48a6-A8E1-A2847082A40E}"
Name="EffectivePolicyDate" Required="TRUE" ShowInNewForm="TRUE"
ShowInEditForm="TRUE"/>
    </FieldRefs>
    <XmlDocuments>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/
v3/contenttype/forms">
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/
v3/contenttype/forms">
          <Display>DocumentLibraryForm</Display>
          <Edit>DocumentLibraryForm</Edit>
          <New>DocumentLibraryForm</New>
        </FormTemplates>
      </XmlDocument>
    </XmlDocuments>
  </ContentType>
</Elements>

When defining the new custom fields for the content type to consume, there are some fields that VSeWSS will give you by default and some fields that can be defined as optional attributes to the field element.

These are simply the fields that are required for the content type field to be acceptable to SharePoint. There are some other optional fields that can be used for things such as indicating that the schema of the content type field is being defined by SharePoint v3.

The following code defines the fields decorated with the relevant attributes (see the table above) that are going to be used by the policy content type, the most important being the ID and Name attributes, which correlate the field to the content type (see Listing A-7).

Example A.7. Policies.Fields.xml

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- Policy Field Types -->
  <Field ID="{78953994-21C2-4737-A7FA-E7FC6019CA74}"
      Name="PolicyID"
      SourceID="http://schemas.microsoft.com/sharepoint/v3"
      StaticName="PolicyID"
      Group="Policy Storage columns"
      Type="Number"
      Sealed="FALSE"
      ReadOnly="FALSE"
      Hidden="FALSE"
      DisplayName="Product ID"
      ColName="PolicyID">
  </Field>
  <Field ID="{358E48C9-D527-4718-BA6F-438A6A12922A}"
      Name="PolicyName"
      SourceID="http://schemas.microsoft.com/sharepoint/v3"
      StaticName="PolicyName"
      Group="Policy Storage columns"
      Type="Text"
      Sealed="FALSE"

ReadOnly="FALSE"
      Hidden="FALSE"
      DisplayName="Policy Name"
      ColName="PolicyName">
  </Field>
  <Field ID="{3FB081E8-C903-48a6-A8E1-A2847082A40E}"
    Name="EffectivePolicyDate"
    SourceID="http://schemas.microsoft.com/sharepoint/v3"
    StaticName="EffectivePolicyDate"
    Group="Policy Storage columns"
    Type="Date and Time"
    Sealed="FALSE"
    ReadOnly="FALSE"
    Hidden="FALSE"
    DisplayName="Policy Effective Date"
    ColName="PolicyEffectiveDate">
  </Field>
</Elements>

A.5.1. Event Handlers

The Content Type Wizard also offers the option to append an event receiver to the content type that you are creating. Adding an event receiver to the content type will add two new .cs files to the item folder: a class inheriting from the SPItemEventReceiver base class to handle item-level events, and an additional class inheriting from the SPListEventReceiver base class to handle list-level events. Within each of these receiver classes, there are the related overridden blank item or list event methods used to capture events as they occur or execute any wrapped logic within each event method. Whenever that specific event is triggered, the receiver class will be called and whatever methods are wrapped within the custom overrides will be triggered and executed. It is important that the same type of receiver architecture be used when appending event receivers to various other Item Templates in VSeWSS.

A.5.2. Event Handlers Provisioned By Default by VSeWSS

With the event handlers that you receive when you generate the receiver through the VSeWSS Wizard, you get both the synchronous events (events triggered before activity) and the asynchronous events (those that are handled after activity is triggered). The following table is a list of events that are overridden when using the VSeWSS table:

When you create a new content type and have VSeWSS provision the receiver for you, you will also get the ListEventReceiver.cs class, which will handle the list events, as opposed to the item event. The following table lists the item events that are overridden when using VSeWSS. This inherits from the SPListEventReceiver base class and has pre- and post-events.

There is a series of event properties that can be used to customize the way that WSS interacts with the user to manage the overall user experience, and that only requires a brief set of custom code in order to populate. Specifically, for the policy management site, you want to make sure that relevant policy documents are not deleted from the policy library. In order to maintain an archive for legal purposes and business regulations, it is best to maintain records of all applicable standards. Therefore, modify the synchronous event before an item is actually deleted to display a message to users that they are about to delete a policy document (see Listing A-8). The code simply fires the pre-ItemDeleting event when a person attempts to delete a document, sending an error message with the cancel property set to true, preventing the actual deletion of the document from the policy library.

Example A.8. ItemDeleting an event handler to display a message to the user

[SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)]
 public override void ItemDeleting(SPItemEventProperties properties)
    {
   string policyDocName = properties.ListItem;
   string currentUser = properties.UserDisplayName;
   string listname = properties.ListName;
   properties.Cancel = true;
   properties.ErrorMessage = "Deleting {0} policy is not allowed {1} from the {2}";
    }