In my last article on document ID we looked at how SharePoint 2010 document center allows you to add new documents to the site and then after they are assigned unique ID – be able to find them by that ID. In past versions the problem was that you have no control on what the resulting ID will end up being.

In SharePoint 2010 – there is no visual way for you to decide what is your ID going to be – however this short screencast talk about how you can implement such a capability by extending document id provider.

First part of the video Michal talks about the concept of document ID and how they can be used. The second part I show Visual Studio code sample as well as a way to deploy the custom provider.

Enjoy!

When provisioning your SharePoint site automatically with a script – you often create site templates for your sites and sub sites to bundle up pieces of functionality such as page layouts and other features to be created and instantiated when a user creates new instance of your site template. One of the most common scenarios is the ability to provision Web Parts and their values on to a page that is a default page of your site template. This will make it look as if default web parts were added to the page when users create new instance of your custom site template.

To get started we will be using one of the out-of-the-box site templates and enhance it. Let’s grab STS template from ([Drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates).  Locate ONET.XML file in your template.

Locate <Configuration ID=”1″ Name=”Blank”>  in the template. Navigate to the <WebFeatures> node. This is where the Web features will be activated when the template is instantiated.

The next step is to create a feature that will create a page upon being called. We will reference that feature right under the Web Features, by using ID just like all of the other features are referenced.

In ([Drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\sts) you will find default.aspxwhich we will include in our feature. The default.aspx  file already has some web part zones which you can change, delete and add new ones as you see fit.

So far our feature definition will look like this:

<?xml version="1.0" encoding="utf-8"?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
 Id="090A251F-86DB-4035-959C-4A3E2FDEA856"
 Title="Provision my page"
 Version="1.0.0.0"
 Scope="Web"
 Hidden="FALSE"
 ActivateOnDefault="FALSE"
 AlwaysForceInstall="TRUE"
 ImageUrl="">
  <ElementManifests>
    <ElementFile Location="Default.aspx" />
    <ElementManifest Location="Default.aspx.xml" />
  </ElementManifests>
</Feature>

That’s Default.aspx.xml  you’re looking at in the feature definition will define what web part are going to show up in which zones. Here is how we typically provision our web parts into zones:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="Content">
    <File Name="Default.aspx"
Url="Default.aspx" Type="GhostableInLibrary">
<AllUsersWebPart WebPartZoneID="LeftZone1" WebPartOrder="1">
        <![CDATA[Your webpart definition goes here]]>
    </File>
  </Module>
</Elements>

That’s about it. Now all you need to do is to reference the feature ID in a WebFeatures section of your onet.xml.

I assume you already know how to provision your site template. Now when users create new instance of your template. You pre-formatted, so to say, page will be provisioned with it.

Good Luck!

If you worked with SharePoint lists and libraries you probably noticed that you have an ability to add an Image type field or a hyperlink. When you add one using SharePoint UI

…. you end up with somehting that looks like this below

which is not so user friendly, because usually content authors ,don’t know whether it is relative URL they have to specify let alone the fact that they now have to go and look for image and then go back to the page.

If you worked with SharePoint Publishing pages before, you remember how publishing pages have a notion of publishing image field that renders like this

In here you can click on the Add Image link and you will get a friendly UI to select image from the site; way better approach. So how can you have the same functionality in your regular document library.

For this I will create a copy of my out of the box document library defined here ([Drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\DocumentLibrary)

then in the schema.xml of the library I will add the following field (along with other fields):

<Field ID="{2E2A32F1-1B2E-4401-9527-7482D2AD0569}"

Type="Image" Name="ThumbImage"

DisplayName="Thumbnail Image" RichText="TRUE"

RichTextMode="FullHtml"

SourceID="http://schemas.microsoft.com/sharepoint/v3"

StaticName="ThumbImage">
</Field>

In here, nothing much more different than deifning a regular image field. The only difference are two attributes: RichText=”TRUE” RichTextMode=”FullHtml” that will actually render appropriate UI.

Once the feature is deployed and activated – now my enhanced document libraries will contain an image picker.

In my next article – I’ll touch on how you can add this field to existing document libraries.

Enjoy!

It’s a common task to search SharePoint lists and libraries using an SPQuery mechanism. The rules are pretty simple, you write a query involving columns and values you would like to filter and get the results back. Things are not that straighforward when you`re dealing with lookup column.

When one of your lists is referencing another using a lookup column in it`s relationship – the format the data gets stored in the column involves the referenced ID delimited by a semicolon and followed by the value. You`d think that by supplying exact same format and values you will get your query working but not so.

In order to filter byb a lookup column – you need to supply LookupId=’True’ attribute and value and then provide just an ID of the looked up item.

In the below example, I use a list called comments to search comments that have been associated with a particular post.

Here is how my query is going to look like:

SPListItemCollection items = commentsList.GetItems(
new SPQuery {
    Query = "<Where><Eq><FieldRef Name='PostId' LookupId='True'/>"+
"<Value Type='Integer'>" +
    properties.ListItemId + "</Value></Eq></Where>",
    RowLimit = 0,
}
);

That’s all there is to it, enjoy!

In SharePoint lookup fields allow you to display information from a parent list in the child list. At the time of you provisioning the child list you must already have a parent list where the field is going to be looked up from.

In case of SharePoint Publishing scenario – when you want your Publishing Pages to have a field that looks up its values from another list – you don’t really have a luxury or defining the way Pages list will look like. At the same time you can’t create a list which is going to be a parent list in lookup relationship because Pages library is the first one that gets provisioned during a site creation.

In this case, the easiest scenario is to create your lookup field on already existing library after all of the dependent components have been created.

Here is how you would go about provisioning your custom lookup field into a Pages library of a Publishing site. This code can be ran as an event receiver, and if you want to run it standalone – you’d obviously modify it a bit.

using (SPWeb web = (SPWeb)properties.Feature.Parent)

{

    if (PublishingWeb.IsPublishingWeb(web))

    {

        PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(web);

        SPList pagesList = pubWeb.PagesList;

        SPList parentList = web.Lists["ParentList"];

        pagesList.Fields.AddLookup("NewLookupField", parentList.ID, true);

        SPField newLookupField = pagesList.Fields.GetField("NewLookupField");

        XmlDocument doc = new XmlDocument();

        doc.LoadXml(newLookupField.SchemaXml);

        XmlNode root = doc.FirstChild;

        XmlNode attr = doc.CreateNode(XmlNodeType.Attribute,

"ShowField", string.Empty);

        attr.Value = "Title";

        root.Attributes.SetNamedItem(attr);

        newLookupField.SchemaXml = doc.InnerXml;

         newLookupField.Update();

    }

}

Above you notice, there is a handy method allowing you to add a lookup to the list, however that one has limited number of properties you can assign and for lookup we need a property that will specify the field name that will be displayed in child list. One way to get around this is to modify field schema; this is how you can modify all of the other attributes/properties of the field that you would normally do in through CAML.

Good Luck!