Corey Roth [MVP] : CAML

How to: Query List Items from the Host Web in a Client Web Part of a SharePoint Hosted app

CoreyRoth — Fri, 26 Oct 2012 13:30:30 GMT

That’s a mouthful, but I wanted to make sure that people knew exactly what this post is for. The problem I am seeing out there already is that while there is a lot of code samples, they aren’t clear for what type of app the sample is for. If you are doing a provider hosted app for example, the way you query list items is different (using the Cross-Domain Library). Today’s topic boggled me though because while I found plenty of samples on how to query list items using CSOM from an app, they were all in-fact incorrect for a SharePoint hosted app. The article I linked is great by the way. It has many of the things you need to know how to do via CSOM in an app so be sure and check it out.

Now to get on to the scenario I want to help you with today. If you are building a Client Web Part, you may have stumbled upon my previous articles on the topic (JavaScript and Getting Started). These are great articles to get you started, however, it turns out I left out the details on how to query list items from a SharePoint hosted app. Like many things, it’s not as simple as I thought it was. I thought it was just a matter of passing another URL into get_web(). I was wrong. I then saw some examples and thought I just need to pass the URL into a new SPContext object. Also wrong. While, you can do that, once you make the call to get your list items, you’ll quickly find yourself with an Access Denied error coming from MicrosoftAjax.js. I gave up and posted something to the forums and luckily Elisabeth Olson from MSFT came through with the answer. In my solution, I start with some global variable declarations.

var context;
var web;
var user;
var spHostUrl;
var parentContext

Then the code looks similar to that from my article on SP.js. In the document ready function, I get the spHostUrl with the following line of code. You can get that getQueryStringParameter method from my previous article as well. Remember, the SPHostUrl comes from the {StandardTokens} parameter in your Client Web Part’s elements.xml file.

spHostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));

Now, we set up our context and here is where things are a bit different. First, we get our context object using SP.ClientContext.get_current() as usual. However, we have to get a new context by using SP.AppContextSite and passing in the current context along with the Host Url.

context = new SP.ClientContext.get_current();
parentContext = new SP.AppContextSite(context, spHostUrl);

After that, we just need to get our SPWeb object using the parentContext.

web = parentContext.get_web();

At this point, it’s business as usual to do our queries. Get the list, set a CAML query, load the getItems call, and then execute the query.

var list = web.get_lists().getByTitle("My List"));
 
var camlQuery = new SP.CamlQuery();
camlQuery.set_viewXml("");
 
this.listItems = list.getItems(camlQuery);
context.load(listItems);
 
context.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded),
    Function.createDelegate(this, this.onQueryFailed));

My success and failure functions are pretty standard in this case. I just manually iterate through the results and return the Title and Id. Otherwise, I display the reason for failure.

function onQuerySucceeded() {
    $("#results").empty();
    var listInfo = '';
    var listEnumerator = listItems.getEnumerator();
 
    listInfo += "<table><tr><th>Id</th><th>Title</th></tr>";
 
    while (listEnumerator.moveNext()) {
        var listItem = listEnumerator.get_current();
        listInfo += '<tr><td>' + listItem.get_item('ID') + '</td>'
            + '<td>' + listItem.get_item('Title') + '</td>'
            + '</tr>\n';
    }
 
    listInfo += '</table>';
 
    $("#results").html(listInfo);
}
 
function onQueryFailed(sender, args) {
    $("#results").empty();
    $("#results").text('Request failed. ' + args.get_message() +
        '\n' + args.get_stackTrace());
}

This threw me for a loop for a while, so hopefully this post helps you get started quicker when you build your app.

Follow me on twitter, @coreyroth, if you have any questions and come see me at SPC if you are going.

How to: Deploy Metadata Navigation without using code

CoreyRoth — Wed, 09 Feb 2011 22:37:29 GMT

As someone who focuses mostly on ECM and Search, I am a huge fan of the new Metadata Navigation feature on document libraries in SharePoint 2010. It provides a great alternative to folders when it comes to navigating your document libraries. A list administrator can configure Metadata navigation on the document library settings page. However, I prefer to make changes using CAML or code so that I can deploy them easily to other environments. Usually, my first choice is with CAML, so I did some digging today and I discovered the trick to deploying your Metadata navigation settings using a SharePoint feature.

When I first started investigating this, I assumed it might be some new element or attribute inside the schema.xml file of the list. It turns out my assumption was incorrect. We actually set this by assigning some XML to the client_MOSS_MetadataNavigationSettings property on the root folder of the list. We can assign this value using code, but you know I prefer to use CAML. We can use the PropertyBag element to make this happen. Before we look at the PropertyBag element itself though, let’s look at the underlying XML. Let’s take my list here with three items selected for Metadata Navigation: a site column named DocumentType, the Content Type of the documents in the library, and the Folders in the library itself. Here is what the XML will look like.

<MetadataNavigationSettings SchemaVersion="1" IsEnabled="True" AutoIndex="True">
  <NavigationHierarchies>
    <FolderHierarchy HideFoldersNode="False" />
    <MetadataField FieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" FieldType="Choice" CachedName="DocumentType" CachedDisplayName="DocumentType" />
    <MetadataField FieldID="03e45e84-1992-4d42-9116-26f756012634" FieldType="ContentTypeId" CachedName="ContentTypeId" CachedDisplayName="Content Type" />
  </NavigationHierarchies>
  <ManagedIndices>
    <ManagedIndex IndexID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" IndexFieldName="DocumentType" IndexFieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" />
  </ManagedIndices>
</MetadataNavigationSettings>

The first line seems to always be the same. It enables the Metadata Navigation and it will take care of automatically adding new index columns when AutoIndex is set to true. The NavigationHierarchies section actually defines which fields will be used for Metadata navigation. If you want to navigate by folders, add a FolderHierarchy element and set HideFoldersNode to false. If you set it to true, folder navigation will not be present. The MetadataField element defines which fields to use for navigation. You need the GUID for each site column to include. You can get this from your list’s schema.xml file. You then need to specify the FieldType. Remember that it only supports Single-value Choice (Choice), Managed Metadata (TaxonomyFieldType) , and Content Type (ContentTypeId) field types. You then need to specify the field name in the CachedName field and then you can customize the display name as you see fit with CachedDisplayName. The last thing to note here is that you have to create a Managed Index for any choice fields you add. This is why you see a ManagedIndex element with the DocumentType field. Set the IndexId and IndexFieldId attributes equal to the Id of the field.

At this point, we are ready to assign this XML to the the client_MOSS_MetadataNavigationSettings property. We need to encode the above XML, because it is being stored inside an attribute of another XML document. Here is what your elements.xml file would look like.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag Url="Shared Documents" ParentType="Folder" RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Property Name="client_MOSS_MetadataNavigationSettings" Value="&lt;MetadataNavigationSettings SchemaVersion=&quot;1&quot; IsEnabled=&quot;True&quot; AutoIndex=&quot;True&quot;&gt;&lt;NavigationHierarchies&gt;&lt;FolderHierarchy HideFoldersNode=&quot;True&quot; /&gt;&lt;MetadataField FieldID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; FieldType=&quot;Choice&quot; CachedName=&quot;DocumentType&quot; CachedDisplayName=&quot;DocumentType&quot; /&gt; &lt;MetadataField FieldID=&quot;03e45e84-1992-4d42-9116-26f756012634&quot; FieldType=&quot;ContentTypeId&quot; CachedName=&quot;ContentTypeId&quot; CachedDisplayName=&quot;Content Type&quot; /&gt; &lt;/NavigationHierarchies&gt;&lt;ManagedIndices&gt;&lt;ManagedIndex IndexID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; IndexFieldName=&quot;DocumentType&quot; IndexFieldID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; /&gt;&lt;ManagedIndex IndexID=&quot;d31655d1-1d5b-4511-95a1-7a09e9b75bf2&quot; IndexFieldName=&quot;Editor&quot; IndexFieldID=&quot;d31655d1-1d5b-4511-95a1-7a09e9b75bf2&quot; /&gt;&lt;/ManagedIndices&gt;&lt;/MetadataNavigationSettings&gt;" Type="string" />
  </PropertyBag>
</Elements>

It’s kind of hard to read the contents of the Property element, but it is just the encoded version of the XML above. As for the PropertyBag element, you just specify the relative Url to the document library on your site. In this case, it’s Shared Documents. Always set ParentType to Folder and RootWebOnly to false. At this point, you can activate this feature after you have deployed your document library and it will enable the Metadata navigation. Here is what the Metadata Navigation settings page looks like.

Here is what my document library looks like with the navigation enabled.

It’s pretty easy to set this up as you can see. Keep in mind that if you set this value, it will overwrite any values previously stored. This includes any Key Filters or Indexes that might already be present on the list.

Speaking of Key Filters, we can add them to the document library using the client_MOSS_MetadataNavigationSettings as well. Let’s look at some more XML. In this case, I am adding key filters for DocumentType, All Tags, and Modified By (editor).

<MetadataNavigationSettings SchemaVersion="1" IsEnabled="True" AutoIndex="True">
  <KeyFilters>
    <MetadataField FieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" FieldType="Choice" CachedName="DocumentType" CachedDisplayName="DocumentType" />
    <MetadataField FieldID="23f27201-bee3-471e-b2e7-b64fd8b7ca38" FieldType="TaxonomyFieldTypeMulti" CachedName="TaxKeyword" CachedDisplayName="All Tags" />
    <MetadataField FieldID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" FieldType="User" CachedName="Editor" CachedDisplayName="Modified By" />
  </KeyFilters>
  <ManagedIndices>
    <ManagedIndex IndexID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" IndexFieldName="Editor" IndexFieldID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" />
  </ManagedIndices>
</MetadataNavigationSettings>

The elements are pretty similar to that of the NavigationHierarchies element. You add one MetadataField element for each field you want with the same attributes as before. However, a few more fields types are supported such as Person or Group (User). It also recognizes Enterprise Keywords through the use of the All Tags (TaxonomyFieldMulti) filter. You can also do Date and Time fields as well as Number fields too. I also added the ManagedIndex field for Editor (the Modified By filter). You can probably leave the indexes out since AutoIndex is true, but if you run into issues, you can add them manually as you see above. You can deploy KeyFilters and NavigationHierarchies elements at the same time. You’ll need to encode the XML again just as you did before. When you activate the feature, you’ll have Key Filters enabled on your document library.

Using the PropertyBag element, you can easily add metadata navigation to your document libraries. This is a great alternative to defining these settings using code.

Deploying an External List via Feature using CAML #sp2010

CoreyRoth — Thu, 25 Feb 2010 19:33:13 GMT

I’ve been talking a lot about external lists lately as you may know. They are so easy to create with SharePoint Designer, but you wouldn’t really deploy them to production that way would you? Of course not! We need a feature. At first, you might think generating all of that CAML might be too difficult, but remember we can use the Save Site as Template page to generate a .wsp file for us. Using this we can import it into Visual Studio and learn what CAML we need to use.

We’re going to start with the same external list from yesterday. You can build your own using SharePoint Designer as described in my BCS post.

Once you are happy with your list, go to Site Settings –> Save Site as Template. Fill in the fields and it will save a solution package in your solution gallery of your site collection. Save the .wsp file to disk and we’re ready to begin. Once you have your solution package, open Visual Studio 2010, create a new project, and use the Import SharePoint Solution Package project template. You will be prompted for what site to use and where the package file is. On the next step, you will be prompted for what you want to import.

The solution package has every site column, content type, page, list, etc, on the site so there is a lot to sift through. However, the only thing we really need is the list instance in question (in my case Products). You will want to unselect everything else as it will take forever to import if you don’t.

Quick Tip: There isn’t a select all button, so press Ctrl+A, and then unclick a checkbox to deselect everything.

On the next step you will get a warning about dependencies. Go ahead and just say yes and your project will import. Your project will likely have a bunch of stuff you don’t really care about. All that you really need is what it is created in List Instances. Your list instance might look something like this.

At this point, I created a new project because I want to keep things clean. Create a new project and create a new List Definition. At this point, you will have a schema file and two new elements files. The elements.xml file with the list template can be deleted since I don’t want users creating new versions of this list. Before we start digging into the CAML that is required to make an external list work, let’s go back and look at SharePoint Designer so we can remember what our application definition looked like.

The reason I show you this is because these values we’re going to see when we take a look at our elements.xml file. Here is the file that came from the site export.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance FeatureId="{00bfea71-9549-43f8-b978-e47e54a10600}" TemplateType="600" Title="Products" 
                Description="" Url="Lists/Products" CustomSchema="Files\Lists\Products\Schema.xml" 
                HyperlinkBaseUrl="http://sp2010/Test" RootWebOnly="FALSE" 
                xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

A couple of things to note here. First, the TemplateType is 600. We can only presume this is the list template id for an external list. The other thing of note is the new DataSource element. This was not in previous versions of SharePoint. As you might notice here, these values correspond to what we see on the external content type. This is what you will change should you decide to rename the entity in or change the LobSystemInstance name. This XML is highly useable in our own feature, but I am going to remove some of the unnecessary attributes such as FeatureId and CustomSchema. I’m also going to give it a new Title so that we know this is a different list. Here is what my new elements.xml looks like.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance TemplateType="600" Title="Products - Deployed by Feature" Description="" 
                Url="Lists/ProductsDeployedByFeature" HyperlinkBaseUrl="http://sp2010/Test" 
                RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

Honestly, I think I can get rid of HyperLinkBaseUrl as well. It doesn’t seem to matter though, I deployed it to a few other sites and it seems to work fine. Now let’s take a look schema.xml. It’s actually pretty small which is nice compared to the files we were used to in the past.

<?xml version="1.0" encoding="utf-8"?>
<List Title="Products" Direction="none" Url="Lists/Products" BaseType="0" Type="600" 
      FolderCreation="FALSE" DisableAttachments="TRUE" Catalog="FALSE" RootWebOnly="FALSE" 
      SendToLocation="|" ImageUrl="/_layouts/images/itgen.gif" xmlns:ows="Microsoft SharePoint" 
      xmlns:spctf="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms" 
      xmlns="http://schemas.microsoft.com/sharepoint/">
  <MetaData>
    <ContentTypes>
      <ContentType ID="0x01" Name="Item" Group="List Content Types" Description="Create a new list item." FeatureId="{695b6570-a48b-4a8e-8ea5-26ea7fc1d162}">
        <Folder TargetName="Item" />
        <FieldRefs>
          <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
          <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" 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>ListForm</Display>
              <Edit>ListForm</Edit>
              <New>ListForm</New>
            </FormTemplates>
          </XmlDocument>
        </XmlDocuments>
      </ContentType>
    </ContentTypes>
    <Fields>
      <Field DisplayName="BDC Identity" Hidden="FALSE" Name="BdcIdentity" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="BdcIdentity" Type="Text" />
      <Field DisplayName="Name" Hidden="FALSE" Name="Name" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Name" Type="Text" />
      <Field DisplayName="Id" Hidden="FALSE" Name="Id" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Id" Type="Integer" />
      <Field DisplayName="Color" Hidden="FALSE" Name="Color" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Color" Type="Text" />
      <Field DisplayName="Description" Hidden="FALSE" Name="Description" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Description" Type="Text" />
      <Field DisplayName="Price" Hidden="FALSE" Name="Price" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Price" Type="Decimal" />
    </Fields>
    <Forms />
    <Views>
      <View DisplayName="Products Read List" DefaultView="TRUE" BaseViewID="1" Type="HTML" MobileView="TRUE" MobileDefaultView="TRUE" ImageUrl="/_layouts/images/generic.png" XslLink="main.xsl" WebPartZoneID="Main" WebPartOrder="1" Url="Read List.aspx" SetupPath="pages\viewpage.aspx">
        <XslLink>main.xsl</XslLink>
        <Method Name="Read List" />
        <Query>
          <OrderBy>
            <FieldRef Name="Name" />
          </OrderBy>
        </Query>
        <ViewFields>
          <FieldRef Name="Name" ListItemMenu="TRUE" LinkToItem="TRUE" />
          <FieldRef Name="Id" />
          <FieldRef Name="Color" />
          <FieldRef Name="Description" />
          <FieldRef Name="Price" />
        </ViewFields>
        <RowLimit Paged="TRUE">30</RowLimit>
        <Aggregations Value="Off" />
      </View>
    </Views>
  </MetaData>
</List>

As you can see it’s pretty clean. It again uses the Type of 600. In the ContentTypes section, it does define a regular list item, but it doesn’t actually add any of the fields from the external list there. The Fields element has a field defined for each field in my external content type. As you can see there is nothing special about the way they are defined. The only one of note is the BdcIdentity field which I assume is required to keep track of the ID that ties back to the BCS itself. The View is surprisingly clean as well. The XslLink and Method elements are new. I assume we can use XslLink to customize how the view is rendered, but I didn’t actually see a main.xsl file generated in the solution package anywhere. The Method element I can only assume corresponds to the name of the finder method Read List which we have seen above. The rest is pretty simple. It just has a FieldRef for each column in my external content type.

I can pretty much use the Schema.xml file as is. I did change the Title and Url attributes at the top but that is it. At this point my new feature to deploy this is ready to go. Here is what it looks like in Visual Studio.

Deploy your solution and have it activate your feature. The new list won’t show up automatically in the navigation on the side, but it will be there. Just go to the URL directly or view the lists on your site to get there. Here it is on my new site.

As you can see it’s really not that hard to deploy an external list to another site properly using a feature. Now, you might have noticed there are a few other elements.xml files generated when we did the site export. One stores specific values in the property bag of the list. This we did not want because we don’t really want to copy those internal properties. The other deals with the forms of the list. It uses the BinarySerializedWebPart which scares me a bit, so I haven’t messed with it much. If you are just using default forms you don’t need to worry about it. In a future post, I’ll try seeing if I can deploy some InfoPath forms along with the list, but I figured that deserves its own post.

Also, one other thing to note. If you are deploying your external content type to another server, you can do that in the same manner as you did in SharePoint 2007. Just export the application definition and import it on the new server. You can also use the Export Application Model button in SharePoint designer on the External Content Types list.

I hope this helps when you look to move lists into production. This technique of exporting and importing will also work with regular lists of course. Just remember, friends don’t let friends deploy lists without a feature.

Does Save Site as Template preserve Version History in sp2010?

CoreyRoth — Thu, 11 Feb 2010 22:18:26 GMT

It looks like the answer is no. When you click the Include Content checkbox on the Save as Template page, it looks like only the latest version of documents and lists items are included in the .wsp file. I ran a few tests and here is what I saw. Consider the following document with its history from the source site.

After I export the site, install and activate the solution on a new site collection and then use the Create Site menu to create a new instance of my site template, only the latest version of the document is there. Now, I’m not complaining as this is already a great step in the right direction and it really does make moving things around between servers easier. In the screenshot below though, you can see that only the latest version is present.

I’m not really sure why it creates two versions of the document (with different file sizes even), but I am sure there is a reason. If you haven’t use Save Site as Template, be sure and check it out. It does export content (including documents). Your documents are packaged up in the .wsp and use the module element to copy them via feature to your document library. Here is what your package looks like in Visual Studio 2010.

As you can tell from my string of posts lately, I am really excited about the Save Site as Template functionality. We all would have killed to have it in WSS3. It really is a great way to see how things are built behind the scenes to using CAML.

Using the PropertyBag element to assign properties to Items in SharePoint 2010

CoreyRoth — Thu, 11 Feb 2010 21:43:28 GMT

When the NDA dropped, I mentioned how you could use the new PropertyBag element in a feature to write values into the property bag of a site. I already thought that was going to be incredibly useful, but it turns out the power of this new element is even greater than I first realized. At the time I noticed that the PropertyBag element had a Url attribute but I didn’t understand what it was used for at the time. Now I do. As I mentioned yesterday, I have been experimenting with exporting sites as .wsp files and I discovered that you can use this to write to properties of an existing list item. Take a look at the following example, that I grabbed from the file it generated when exporting my site. This applies properties to default.master.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag Url="_catalogs/masterpage/default.master" ParentType="File" RootWebOnly="FALSE" HyperlinkBaseUrl="http://sp2010/Test" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Property Name="vti_charset" Value="utf-8" />
    <Property Name="vti_candeleteversion" Value="true" />
    <Property Name="vti_modifiedby" Value="SHAREPOINT\system" />
    <Property Name="vti_cachedneedsrewrite" Value="false" />
    <Property Name="vti_level" Value="1" />
    <Property Name="vti_rtag" Value="rt:7CDE768C-FCE1-46E8-9165-FDA564419D9A@00000000002" />
    <Property Name="vti_cachedbodystyle" Value="&lt;body scroll=&quot;yes&quot; onload=&quot;BLOCKED SCRIPTif (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();&quot;&gt;" />
    <Property Name="vti_title" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="UIVersion" Value="3" />
    <Property Name="vti_parserversion" Value="14.0.0.4536" />
    <Property Name="vti_cachedhastheme" Value="false" />
    <Property Name="vti_foldersubfolderitemcount" Value="0" />
    <Property Name="vti_hasdefaultcontent" Value="true" />
    <Property Name="vti_setuppathversion" Value="4" />
    <Property Name="vti_metainfoversion" Value="2" />
    <Property Name="vti_canmaybeedit" Value="true" />
    <Property Name="vti_generator" Value="Microsoft SharePoint" />
    <Property Name="vti_etag" Value="&quot;{7CDE768C-FCE1-46E8-9165-FDA564419D9A},2&quot;" />
    <Property Name="vti_cachedtitle" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="vti_contentversion" Value="0" />
    <Property Name="vti_progid" Value="SharePoint.WebPartPage.Document" />
    <Property Name="vti_timelastmodified" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_sourcecontrolversion" Value="V1.0" />
    <Property Name="vti_timecreated" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_folderitemcount" Value="0" />
    <Property Name="vti_docstoretype" Value="0" />
    <Property Name="ContentTypeId" Value="0x01010500CE60EDAC92E8C942BFB82AF8AFC4A5F4" />
    <Property Name="vti_filesize" Value="29039" />
    <Property Name="vti_sourcecontrolcookie" Value="fp_internal" />
    <Property Name="vti_author" Value="SHAREPOINT\system" />
    <Property Name="vti_setuppath" Value="global\default.master" />
    <Property Name="vti_metatags" Value="GENERATOR Microsoft\ SharePoint progid SharePoint.WebPartPage.Document HTTP-EQUIV=Content-Type text/html;\ charset=utf-8 HTTP-EQUIV=Expires 0" />
    <Property Name="vti_replid" Value="rid:{7CDE768C-FCE1-46E8-9165-FDA564419D9A}" />
    <Property Name="vti_docstoreversion" Value="2" />
    <Property Name="vti_cachedcustomprops" Value="vti_title" />
  </PropertyBag>
</Elements>

As you can see the relative URL of the file is specified along with a separate attribute indicating the base URL it came from. You also need to specify something for ParentType. For now I know that you can specify File or Folder there (although I am guessing it might take Item or something like that).

Now for the most part all of these properties listed above are internal properties that you would never care about setting, but as you guessed you can specify your own properties as well. The export site as template functionality does its best to export everything it can and that includes internal properties as well. This is pretty interesting feature and I think it could remove the need to write a lot of code in my future. @SPKyle might still want to write code to store properties on list items, but I will take a pass. :)

Deploying Relational Lists using CAML in SharePoint 2010

CoreyRoth — Wed, 10 Feb 2010 20:46:20 GMT

One of my favorite new features in SharePoint 2010 is the ability to have lists relate to each other and the fact that you can maintain referential integrity. Now, I am sure there are at least 50 posts out there already that show you how to do this using the UI. The UI is great, but you are a developer and that means you might want to actually deploy these lists elsewhere someday. Now I have to admit, using the save site as template feature is great for moving sites and content around but you may want a more granular deployment of a pair of lists in a single feature. The cool thing is the save site as template feature is extremely useful for discovering the underlying CAML to build things in SharePoint which is how I discovered relational lists work today. This post has some great screenshots of how to export a site template as a wsp.

For today’s example, I have a list of categories and a list of products. The products list has a lookup column which references the categories list. Here is what the products list looks like.

On this view, you can see that I am linking to the Categories list and I am displaying the Id and Description from that list. Here is how my lookup column is defined.

Creating a list with CAML in SharePoint 2010 is really not much different than in previous versions. In order to set up this lookup column, we need to look at the Schema.xml of the Products list. It turns out that the column that the user chooses is still a lookup column but so are the additional fields. They just have additional attributes defined. Let’s look at the definition of the lookup column the user interacts with first.

<Field Type="Lookup" DisplayName="Category" Required="FALSE" EnforceUniqueValues="FALSE" List="Lists/Categories" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" Indexed="TRUE" RelationshipDeleteBehavior="Cascade" ID="{c59b5e18-54c2-408a-a231-b88c3e939e90}" SourceID="{$ListId:Lists/Products;}" StaticName="Category" Name="Category" RowOrdinal="0" />

I got this schema by doing an export as mentioned above. There are a few things you might notice here. The list name and SourceID refer to the lists by URL instead of a hardcoded Id. The value of Indexed is also set to true. This is because relational lists require indexed columns. You also get prompted to index the column when you set it up through the UI. The last thing to note is the RelationshipDeleteBehavior attribute. It can have a value of Cascade, Restrict, or none. This corresponds to relationship behavior you see in the UI screenshot above.

The additional fields from the parent list are also lookup fields. They just have a few key differences.

<Field Type="Lookup" DisplayName="Category:ID" List="Lists/Categories" WebId="8c918dd2-ef1f-4822-b3d2-f587d622d203" ShowField="ID" FieldRef="c59b5e18-54c2-408a-a231-b88c3e939e90" ReadOnly="TRUE" UnlimitedLengthInDocumentLibrary="FALSE" ID="{2264d6b5-7001-40e1-b295-236b9965c833}" SourceID="{$ListId:Lists/Products;}" StaticName="Category_x003a_ID" Name="Category_x003a_ID" />
<Field Type="Lookup" DisplayName="Category:Description" List="Lists/Categories" WebId="8c918dd2-ef1f-4822-b3d2-f587d622d203" ShowField="Description" FieldRef="c59b5e18-54c2-408a-a231-b88c3e939e90" ReadOnly="TRUE" UnlimitedLengthInDocumentLibrary="FALSE" ID="{a0ab273e-5989-42ba-950d-3add1c1025e0}" SourceID="{$ListId:Lists/Products;}" StaticName="Category_x003a_Description" Name="Category_x003a_Description" />

First, the FieldRef attribute has the Id of the first lookup field we defined. This is what ties them together. The second thing is that the ShowField attribute refers to the name of the field in the lookup list. The last thing to note is that they are marked as readonly. One more thing to point out is that the static name is encoded with x003a which is the color you see in the DisplayName. This is also used in the FieldRef elements you will also have on any ConentType element thats uses these fields in your schema.xml. For example.

<FieldRef ID="{c59b5e18-54c2-408a-a231-b88c3e939e90}" Name="Category" Required="FALSE" />
<FieldRef ID="{2264d6b5-7001-40e1-b295-236b9965c833}" Name="Category_x003a_ID" ReadOnly="TRUE" />
<FieldRef ID="{a0ab273e-5989-42ba-950d-3add1c1025e0}" Name="Category_x003a_Description" DisplayName="Category:Description" ReadOnly="TRUE" />

You might not see much value in this post yet, but I think you might in the future. The tools to work with SharePoint have improved greatly, but you still will need to work with some CAML from time to time I believe. You may not be building it from scratch any more, but it is still good to know your way around it. As a developer I often get frustrated when I run into posts showing how to do something through the UI when I really need to know how to build something declaratively or programmatically. Hopefully this will be helpful.

SPQuery Error: Microsoft.SharePoint.SPException was unhandled by user code. Cannot complete this action. Please try again.

CoreyRoth — Tue, 26 Jan 2010 21:05:09 GMT

When I get an error, I like to blog about it. Especially when the error gives you no useful information whatsoever. Now, you can get the above error in a variety of ways, but the one I am going to discuss today is when using SPQuery. I inherited some code that had some CAML queries in it and I could not figure out what the cause was at first. When I called SPList.GetItems(SPQuery), I would receive something like the following.

Microsoft.SharePoint.SPException was unhandled by user code
Message="Cannot complete this action.\n\nPlease try again."
Source="Microsoft.SharePoint"
ErrorCode=-2147467259
StackTrace:
       at Microsoft.SharePoint.Library.SPRequest.GetListItemDataWithCallback(String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pSchemaCallback)
       at Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData()
       at Microsoft.SharePoint.SPListItemCollection.get_Count()
       at Samson.P2S.SharePoint.Services.Synchronization.P2S_SynchronizationService.<>c__DisplayClass6.<GetInventoryChecklist>b__4() in C:\Projects\SamsonTFS\P2S\P2S_V0\Samson.P2S.SharePoint.Services.Synchronization\P2S_SynchronizationService.asmx.cs:line 166
       at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
       at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
       at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
InnerException: System.Runtime.InteropServices.COMException
       Message="Cannot complete this action.\n\nPlease try again."
       Source=""
       ErrorCode=-2147467259
       StackTrace:
            at Microsoft.SharePoint.Library.SPRequestInternalClass.GetListItemDataWithCallback(String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pSchemaCallback)
            at Microsoft.SharePoint.Library.SPRequest.GetListItemDataWithCallback(String bstrUrl, String bstrListName, String bstrViewName, String bstrViewXml, SAFEARRAYFLAGS fSafeArrayFlags, ISP2DSafeArrayWriter pSACallback, ISPDataCallback pPagingCallback, ISPDataCallback pSchemaCallback)
       InnerException:

The cause is actually simple. My CAML query was malformed. Specifically my where clause was not nested properly. The previous developer put three conditions in an and clause and that simply does not work. A COM exception though? Really? Wouldn’t it have just been better if it validated the query first and gave us a nice error message such as the following?

CAML query is malformed.

That would be too nice I guess. Anyhow, if you get this when querying, start looking at that query. While, I am here, I’ll remind you if you copy the query from CAML Query Builder, to remove the Query element. If you can’t figure it out and first, go back to the CAML query building tool of your choice and start executing the query there and comparing it to the one you have. You should be up and running in no time.

Enabling Content Approval on a List using CAML

CoreyRoth — Thu, 08 Oct 2009 22:16:42 GMT

I’ve always liked the power of CAML because it allows me to create so much in SharePoint without ever having to write a line of code. However, there really isn’t enough examples out there, so I like writing posts like these that focus on doing something very specific with a list. @SPKyle would say just write some code to do that, but that’s not my style, so I did some digging through the SDK and some experimentation and I figured out how to do it. Of course there isn’t an attribute called EnableContentApproval. So, the first thing we have to figure out is what CAML calls content approval. It turns out CAML refers to this as moderation. We’ll add this to the SharePoint UI to API translation guide. Looking at the List element, I find two attributes ModeratedList and ModeratedType. The description of the both is quite similar, so I decide to try them out one at a time. I find that setting ModeratedList works but setting ModeratedType does nothing. No idea why there is two attributes. Maybe one is deprecated. Here is what a List element line would like in your schema.xml.

<List xmlns="http://schemas.microsoft.com/sharepoint/" BaseType="0" DisableAttachments="True" EnableContentTypes="True" Name="MyList" OrderedList="False" QuickLaunchUrl="True" Title="My List" Type="10001" VersioningEnabled="False" Url="Lists/MyList" Id="ed65344b-0399-4c34-8265-de0c2d193165" ModeratedList="TRUE">

I then go take a look at the list versioning settings of my newly created list, and everything looks good. Note, if you want to turn on versioning, you can use the VersioningEnabled attribute that you see above.

Again, I set the ModeratedList attribute in the List element of the Schema.xml. Before I set it on the schema.xml file, I noticed that the ListTemplate element that you use in your elements.xml file had an attribute EnableModeration. The SDK states this can be used to turn on moderation as well. However, when using it I find that it does not work. If I set it to true or false it does not work and does not seem to override I set in the schema.xml file. Anyhow, if you ever need to turn on content approval and don’t feel like writing code, I hope this helps.

Error: Reference to undeclared namespace: ‘ns1’ when trying to create a custom Document Information Panel

CoreyRoth — Tue, 29 Sep 2009 21:40:31 GMT

I’ve been chasing this particular error for a little while and thought I would take the time to share my experience and how to resolve it. The scenario I had is I have a custom content type with several custom site columns. I generated the CAML for my content type and site columns using SPSource. When I clicked on the Create a new custom template button, I received the following error (or one similar).

propertySchema0.xsd#/schema/element[1][@name = 'properties']/complexType[1]/sequence[1]/element[1][@name = 'documentManagement']/complexType[1]/all[1]/element[1]

Reference to undeclared namespace prefix: 'ns1'.

As with all InfoPath errors, this is completely useless. After many attempts at trying to figure out this issue, I noticed that I could create a new Lookup Column and a new Content Type using the SharePoint UI and not receive this error. I then busted out the Imtech Fields Explorer and as far as I could tell all of the properties were just about the same. However, I noticed one difference in the SchemaXML property. My Field element did not have a SourceId but the column created through the UI did. It’s value was set to the Id of the web hosting the site column. I knew I couldn’t set it to that and so I remembered in the past I had always set the SourceId of the field element as seen below.

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

This got me closer, the content types and site columns deployed correctly and the SchemaXML had a SourceID in it. However, when I tried to create a Document Information Panel this time, I got this new lovely error.

InfoPath has encountered an error. The operation failed.

Catastrophic failure

Once again, thanks InfoPath team for such useful error information. After further investigation, I discovered I needed to set the StaticName attribute as well. I simply set this to match the Name attribute I had and everything works now. It’s strange how the content type can work completely everywhere else, but in InfoPath it’s very picky. Here is what a complete working Field element might look like for you.

<Field Type="Text" DisplayName="MyField" Required="FALSE" MaxLength="255" Group="My Field Group" ID="{2E6858a5-6ae2-409f-8492-fa15c39821c8}" Name="MyField" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="MyField" />

I mentioned above the issue I had was with a Lookup column but I quickly discovered that this was happening with all of my columns and had nothing to do with the lookup. SPSource has saved me a ton of time, but this is just another minor thing to look out with the tool. I logged an issue on CodePlex to see if we can get these two attributes added to the Site Column export. If you aren’t customizing Document Information Panels, then there is nothing to worry about with the exported CAML, but if you are be sure and add these two attributes.

Using CAML to deploy a lookup column via Feature

CoreyRoth — Wed, 02 Sep 2009 21:47:49 GMT

This week, I needed to deploy lookup columns to some of my lists and as usual I wanted to avoid writing code at all costs. As some of you may know, Kyle Kelin and I debate this topic often as he prefers a code approach. I figured it had to be possible with CAML, but many claimed it was not even possible. A few approaches showed up out there involving using code to modify the elements.xml file with your GUID, but that just wasn’t going to cut it for me. One popular post on the topic by Josh Gaffey, started me in the right direction, but there were a few hurdles I ran into as I was trying to implement it. It would create the list, show the content type, and site columns, but when I tried to create a new item, the lookup column was not there. The basic technique is that you specify the path to the list in the form of (Lists/MyListName) in the List attribute of the Field element in both your schema.xml file of your document library template as well as the definition of the site column. The first thing I learned here is that you cannot simply omit declaring site columns and a content type out and go with list level columns. It simply will not work (no idea why).

Here is how I ended up getting everything to work. I created my initial lists, content types, and site columns through the SharePoint UI. I then used SPSource (seriously a great tool) to export the content type, site columns, and lists (both the source list and the one that contained the lookup column). My goal was to deploy these items to another site collection. I recommend creating separate features for your content types and the list definition. This way you can ensure the content type is deployed first. To export your content type / site columns, create a new stub feature.xml file as described on their site and then create an .spsource file with just the content type in it like this (no need to specify columns).

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType Name="Test" />
</Elements>

In my example, my content type was called Test. Create a separate feature folder for your list template and instance. Create another feature.xml and an .spsource file for the list which looks something like this. My list is also named Test in this case.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListTemplate Name="Test" />
</Elements>

SPSource does a good job when it exports my list definition and properly specifies the list using a path instead of a guid in my lookup column as shown below (from schema.xml).

<Field Type="Lookup" DisplayName="DocumentCategory" Required="FALSE" List="Lists/Categories" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" Group="My Group" ID="{9266e0fa-ae49-438c-acdc-73063684ac8f}" SourceID="{50b253e5-e90e-4781-8fce-cece417b185e}" StaticName="DocumentCategory" Name="DocumentCategory" Customization="" ColName="int1" RowOrdinal="0" />

We don’t actually have to change a thing in this file. What I did have to change is the List attribute of the file it generated for my site columns. As Josh’s post above stated, we have to change the List attribute from a GUID to the path of the list. His post also mentioned you might want to set the PrependId attribute but I have since learned that this is only used when you are using the LookupMulti type (although I can’t remember the source I got this from).

<Field Type="Lookup" DisplayName="DocumentCategory" Required="TRUE" List="Lists/Categories" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" Group="My Group" ID="{9266e0fa-ae49-438c-acdc-73063684ac8f}" Name="DocumentCategory" />

At this point you can deploy your site columns, content type, and then custom list (in that order) and if all goes well you will be able to create a new item of that content type with the lookup column functioning. One thing to note, if you get this wrong, your list will behave oddly. One thing I noticed is that it won’t turn on content types for the list when that happens. If this is happening go back and check your work. Another thing people mentioned is that the source list for the lookup column has to exist before you create the lookup column. This in fact is not true. It will work and it will display a drop down list for the lookup column, but it will be empty of course since the list does not exist.

Along the way I figured out a few other things. When I was trying to figure this out, I was trying to just create the content type and then manually add it to the list via the UI. Doesn’t work. If you try to add a content type with a lookup column defined in this way to an existing list, you will get the following error.

Exception from HRESULT: 0x80040E07 at Microsoft.SharePoint.Library.SPRequestInternalClass.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)
at Microsoft.SharePoint.Library.SPRequest.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)

The only way to get the content type associated with the list is via CAML when it is created. Another odd thing is that the lookup column never shows it is bound to the other list correctly. Here is what the source lookup column looked like.

Notice where it says Get information from, the name of the list is present. Here is what my copy of the list looks like.

Notice that the list name is not present. Strangely enough though, everything works fine in the copy. This one through me for a loop for a while because it didn’t seem like things weren’t working and as I mentioned above I couldn’t add the content type to a list (nor could I add the column to a content type).

As you can see there are few oddities about deploying lookup columns in this manner, but it does work. @SPKyle informed me he could have written code to do this hours ago, but I am quite happy that I can deploy things in this manner now.

Twitter: @coreyroth

Code Samples from our CAML vs API talk at Tulsa SharePoint Interest Group

CoreyRoth — Tue, 12 May 2009 15:36:00 GMT

Last night, Kyle Kelin and I had the opportunity to debate SharePoint provisioning methodologies at the Tulsa SharePoint Interest Group. We each had to deploy a custom site with site columns, a content type, a list, and pages. Kyle chose the API approach and I went with the CAML approach. We ended up having a good interactive discussion with the group on the pros and cons of going with either approach. I also took a minute to show how @jthake’s SPSource can generate CAML for you and the response was great. As promised here is the code samples from the demo last night. Thanks for coming.

Follow Kyle and I on twitter.

Kyle and I are speaking at Tulsa SPIG this Monday

CoreyRoth — Fri, 08 May 2009 14:49:21 GMT

Kyle Kelin and I are doing our first joint talk together at the Tulsa SharePoint Interest Group this Monday, May 11th. We’re going to be talking about Site Provisioning and let the audience decide what they like better: CAML or the API. I also plan on demonstrating the use of the SPSource tool recently release on CodePlex by @jthake. We start at 6pm at TCC Northeast (3727 N. Apache). We hope to see you there.

Kyle Kelin on twitter.

Corey Roth on twitter.

My First Experience with SPSource

CoreyRoth — Mon, 04 May 2009 16:45:36 GMT

If you pay attention to twitter at all, today you might have heard about a new tool on CodePlex called SPSource. SPSource is a tool that reverse engineers existing Content Types, Site Columns, Lists and more on an existing SharePoint site. This isn’t just a re-tweet style post that tells you its out there. I actually took a few minutes today to try it out and so far I am very impressed. Kyle Kelin and I have often talked about the need for a better tool that worked better than VSeWSS Solution Generator. Already, I think this tool is it. Finally you can design a content type in the UI and be able to extract it easily as a feature.

Downloading the tool from CodePlex, gives you an installer for the SPSource executable. The tool is a command line app designed to be executed in a batch file. To get started with the tool, you need to create a local 12 hive folder. You can do this inside Visual Studio manually or with a tool like wspbuilder. For my test purposes, I just created a 12 hive folder in a temp directory and started working. Before you begin, you will need to create a folder to hold your feature as well as a simple feature.xml file. The contents of the file don’t need to contain much, just some XML for deploying a simple feature. The next thing you need to do is identify what you want to extract from your SharePoint. In my case I wanted to extract some content types and a list template. You then create a special XML file with the .spsource extension. This uses the same syntax as any elements.xml file, but it is used to specify which items to extract from SharePoint. The only thing you need to specify is an element such as ContentType or ListTemplate and the name. It then uses this name to look up the resource in SharePoint and extract it. Here is an example of what it looks like.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType Name="My Test Content Type" />
  <ListTemplate Name="My Custom List" />
</Elements>

SPSource will take this information and generate the XML files I need to deploy these items elsewhere. You run SPSource with the following syntax.

spsource.exe –designsite http://my-moss-server/site

When the tool is executed, it will iterate through any subfolders looking for .spsource files. When it finds them, it will create XML files representing the type of items you request (in my case a ContentType and a ListTemplate). It will also update the Feature.xml file in that folder to point to any new .XML files it creates. So far I have found the XML it generates to be very usable and way more accurate than what SPSolGen gives you.

This tool is really nice. I would like to see some more documentation for it, but I am sure that will come as the tool is developed more. When you first install it, all you are given is a link to the CodePlex site in your start menu, so you are left a little bit wondering what to do next. I would love to see more command line options such as just passing it a URL and it extracts the list template. One thing I noticed is that it didn’t extract the ItemEventReceivers definition I had on my content type. I am not complaining though since this tool already has the power to save me a ton of time in the future.

Great work @jthake and everyone else that worked on it. Microsoft should have provided a better tool to do this years ago. I am glad you all stepped up to fill in the gap.

Follow me on twitter.

Using CAML to add Web Parts to an existing page

CoreyRoth — Mon, 15 Sep 2008 21:04:18 GMT

In the past when I thought of how to do this, I tended to over analyze it a bit. I always assumed there was something special in how you do this, but in reality, it is not much different than adding web parts to a new page. I am not sure if this is the best way to do it and it only works in some cases, but it's a start and maybe somebody else can help out. The main thing I was trying to avoid was having to write code in a feature receiver to accomplish this. In today's example, we are going to assume I have a page called default.aspx on a site and it has a web part zone called Left (like many default page templates do). To make this happen, I basically write CAML that is just like if I was creating a new page. This includes getting a copy of a default.aspx page (any one will do that has similar names for web part zones) into a new feature. In this case, I am using the default.aspx file from the STS site template located at 12\TEMPLATE\SiteTemplates\sts. In my elements file, I start by adding a Module and File block like below.

<Module Name="DWS" Url="" Path="dws">
  <File Url="default.aspx" IgnoreIfAlreadyExists="TRUE">

The module Name you specify is DWS (which I believe is the name of the list that pages are stored in). The Path is specified as dws as well assuming I stored my local default.aspx in a folder of that name. You can choose to use a path or not. It shouldn't matter. I then specify the filename with the IgnoreIfAlreadyExists attribute set to true. I believe this results in SharePoint not trying to create a new page if one of that name already exists. After you have your file element it is just a matter of specifying your web parts as usual.

<AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
  <![CDATA[
              <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
                  <Assembly>Microsoft.Office.Server.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
                  <TypeName>Microsoft.Office.Server.Search.WebControls.SearchPagingWebPart</TypeName>
                  <Title>$Resources:spscore,SearchPagingWP_Title;</Title>
                  <Description>$Resources:spscore,SearchPagingWPWP_Desc;</Description>
                  <PartOrder>1</PartOrder>
                  <FrameType>None</FrameType>
                  <AllowMinimize>true</AllowMinimize>
                  <AllowRemove>true</AllowRemove>
                  <IsVisible>true</IsVisible>
              </WebPart>
          ]]>
</AllUsersWebPart>

Every time the feature is activated, it will add the web parts you specify to the file that you specify. This ends up working pretty well, but keep in mind there is nothing built in to delete your web parts off of your web page. If you want to do that, you are going to have to write code in a feature receiver to remove the web parts (a post which I still need to write). Anyhow, I guess what I am saying is that it really isn't any more complicated than adding web parts to a new page. I am not sure if this is the best way to do it so if you have a better idea be sure to leave a comment.