Populating data sources in code

furuknap — Fri, 25 Jul 2008 09:28:27 +0000

Let’s say you want to aggregate news articles from any sub site in a site collection. Now, it would be easy to do this statically using a linked data source as AggregateDataSource and SharePoint designer. However, what if the sub sites change? You will have to remake the data source in SPD or even by hand.

Now, some will argue that you can use a cross site SPDataSource to accomplish this, and more, and they would of course be right. There are far simpler ways of getting to the end result, but the point of this article is to show you how to modify components runtime. If you wanted to make a simple aggregator, use Content Query Web Part, a cross site SPDataSource or even RSS. If you want to learn runtime modification of a component, read on.

Just to make sure you know where we stand, I’ll explain the AggregateDataSource and how to make a linked data source in SPD. Even if you know how to do this, please follow the example so you understand the problems we face when we have a dynamic site structure and understand the site structure from which we are trying to aggregate.

First, we begin by assuming the following site structure:

Now, in each of these sub sites we have a custom list called ‘Articles’ containing at least the fields ‘Title’ and ‘Pri’. We want to have a web part that aggregates all the titles from all the articles, sorted by Pri.
If the site structure is static you can accomplish this by using what is called a linked data source. To create one, start up SPD and go to the Data Source Library. On the very bottom, click ‘Connect to another library…’ Then, for each sub site in the structure, click Add and enter a name and the location of the sub site.

Click image to open larger screenshot in new window

If you look at the Data Source Library again, you will notice that among the data sources available to you, you now have access to all the lists in the sub sites you entered. You can add any list or data source as a web part to a page. However, we want to aggregate all the articles from several lists, and for this we need a linked data source.

Expand the ‘Linked sources’ node and click ’Create a new Linked Source…’ and then [Configure Linked Source…]. For each of the sub sites you added earlier, double-click the Articles-lists to add them to the ‘Selected data sources’ list and then click Next.

Click image to open larger screenshot in new window

On the next page, make sure that you select the ‘Merge’ option, and then click Finish. If you like, go to the General tab and add a name, description and keywords for this data source. When done, click Ok.

Once created you can drag-and-drop the new data source to a page to create a DataFormWebPart (DFWP) with the merged articles. You can work with the DFWP just as you would any other DFWP with a single list data source. Format it, add or remove fields, apply layouts, do what you want.

Click image to open larger screenshot in new window

This is useful for static site structures where the lists are pre-defined or very rarely changing. However, should you chose to add, edit or remove sub sites containing information you want aggregated you need to modify your data source.

Now, if you watch the web part in code view in SharePoint Designer you will see that what you have added is actually a normal DataFormWebPart with a child element called DataSources, marked in the screenshot by a green line, containing an AggregateDataSource. The tags, such as DataFormWebPart are just ordinary .net classes represented as markup. As such we can easily manipulate the contents of the tag and thus the behavior of the class using custom code. This is how we can create a dynamic AggregateDataSource.

First things first, we need a DataFormWebPart whose DataSources we will manipulate. Create a new aspx-page, give it a name (mine is called MyTestPage.aspx), and drag your newly created Linked DataSource onto the design canvas in SPD. Feel free to change layouts or anything else as mentioned above.
Now, you may ask: If I am going to write code to manipulate the DataSources, why not just write code to create the whole DataFormWebPart? Great question, I am glad you asked.

The short answer is: It is easier.

The longer answer is: Well, if you do that you either need to inherit or create the design-capabilities of your custom DataFormWebPart. By using a DFWP that already exists you can format, layout and manipulate that using the built-in design capabilities and only worry about what data will be displayed, not how. Designers will love you for this; they get to go bananas making the thing look beautiful and you get to drop your custom component someplace on the page and change the data that is getting displayed. Good development practice isolates presentation from data.

Let’s get down to the code, shall we.

Start by creating a simple custom component. If you have not done this before I have written an article that will guide you through the steps of creating a simple custom component, at http://furuknap.blogspot.com/2008/05/creating-your-own-custom-components-for.html. However, contrary to that example, do not override the RenderContents method but rather the OnLoad method. If you don’t want to write all the code I’ve attached a ‘Begin’ solution for Visual Studio 2005. Look at the very end of this article for it. Just do it now, and then come back. I’ll wait right here for you.

Overriding OnLoad ensures that when the component is loaded we can access the DataSources of the DFWP. The OnLoad event happens before the DataBinding events so by changing the DataSources in OnLoad we make sure we set the DataSources at the right time. This is important, once the DataBinding methods have been run there is no way to manipulate them and get the result displayed.

   33         protected override void OnLoad(EventArgs e)

   34         {

Since we are going to manipulate an existing DataFormWebPart control, we need some method of identifying and accessing that control. We also need some way of knowing which lists we want to aggregate. Lets solve these problems by adding a few properties to our control. Add the following lines to your class:

   17         private string m_DataFormWebPartId;

   19         public string DataFormWebPartId

   20         {

   21             get { return m_DataFormWebPartId; }

   22             set { m_DataFormWebPartId = value; }

   23         }

   25         private string m_ListName;

   27         public string ListName

   28         {

   29             get { return m_ListName; }

   30             set { m_ListName = value; }

   31         }

Doing this allows us to configure the component at design-time. The public properties are used as part of the asp.net tag, for instance DataFormWebPartId=”MyDFWPId” ListName=”Articles” runat=”server”/>

Now what we have a way of identifying the DFWP and the listnames to aggregate we need to gain access to the DFWP DataSources. Then we can start manipulating the datasources. Add the following code to the OnLoad method:

   35             DataFormWebPart m_dfwp = this.Page.FindControl(DataFormWebPartId) as DataFormWebPart;

   37             m_dfwp.DataSources.Clear(); // Empty datasources

   39             AggregateDataSource ads = new AggregateDataSource();

   40             int sourceCounter = 0;

   41             SPWeb web = SPContext.Current.Web;

   42             StringBuilder aggregateString = new StringBuilder();

   44             aggregateString.AppendLine("");

In line 35 we get the reference to the DFWP. Line 37 clears the current datasources. Lines 39-44 creates objects and variables we need to build our DataSources. I’ll explain some of these a bit later.

Lookup back at the markup of the DFWP, specifically the DataSources tag:
2
3
4
5       ”>
6
7
8
9
10
11
12
13
14
15
16
17
18
19       ”>
20
21
22

…etc. The code has been abbreviated to save space.

This markup reveals how the DataSources work and what we need to create using code. First, as stated in markup line 3, there needs to be an AggregateDataSource, which we create in codeline 39. This in turn contains a property, in markup line 4, called Sources. The Sources property, although we do not know exactly what type it is only from the markup, seems to contain a collection of several SPDataSources, markup lines 5 and 19, which in turn contains a set of Select-, Delete-, Update-, and Insert Parameters objects each.

In addition, after the Sources tag of the AggregateDataSource there is a tag called aggregate containing some strings.

110
111
112
113
114
115
116
117
118
119
120

In the AggregateDataSource class, this property is not, despite its appearances, a collection, but a string. It would make sense to have the aggregate property as a collection so we can just add items to it, but for some reason, this is not so. We therefore need to build this string, using unique names and id values for each datasource we want to add. This is why we have the sourcecounter int and stringbuilder aggregateString in the code, lines 40 and 42.

So, based on this we can start thinking of how our component should build the DataSources. We have our AggregateDataSource, now we need to start adding SPDataSources to its sources property.

Since we want to aggregate from several subsites it makes sense to use a recursive function, and lets call it getSubWebItems. Now, in my implementation I will be breaking some best practices regarding recursive functions, but bear with me, I’m doing this as a sample, you will likely want to implement your own recursiveness.

The signature of the function could be something like this:
private void getSubWebItems(AggregateDataSource ads, ref int sourceCounter, StringBuilder aggregateString, SPWeb web)
The function will then use the web and sourceCounter objects to manipulate the ads and aggregateString objects. Let’s take a look:

   57         private void getSubWebItems(AggregateDataSource ads, ref int sourceCounter, StringBuilder aggregateString, SPWeb web)

   58         {

   59             try

   60             {

   61                 SPList list = web.Lists[m_ListName];

   62                 SPDataSource sds = new SPDataSource();

   63                 Parameter p = new Parameter();

   64                 p.Name = "ListId";

   65                 p.DefaultValue = list.ID.ToString();

   66                 sds.SelectParameters.Add(p);

   68                 p = new Parameter();

   69                 p.Name = "WebURL";

   70                 p.DefaultValue = web.ServerRelativeUrl;

   71                 sds.SelectParameters.Add(p);

   73                 sds.DataSourceMode = SPDataSourceMode.List;

   74                 sds.UseInternalName = true;

   76                 sds.SelectCommand = "";

   77                 ads.Sources.Add(sds);

   79                 aggregateString.AppendLine(" + m_ListName + sourceCounter + "\" id=\"" + sourceCounter + "\" Type=\"SPList\"/>");

   80                 sourceCounter++;

   82             }

   83             catch (Exception)

   84             {

   85                 // Add your own error handling

   86             }

As good developers we always use try-catch, right? Right. Lines 59 and 83-86 handle that. And yes, you need to add error handling.

Line 61 gets a reference to the ListName we have configured in our component from the current SPWeb. Line 62 creates the SPDataSource we need to add to the ads.DataSources. We then start adding the parameters (lines 63-71), and contrary to what the markup code shows, we only add the select parameter. You may want or need to add the other insert, update, and delete parameters as well, depending on wheter or not you want the dataformwebpart to be editable. Of so, follow the selectparameter template.

Lines 73-76 finish configuring the SPDataSource before we add it to the ads.Sources property in line 77.
Remember that strange aggregate string which looked like a collection? Well, as it is only a string, we need to build that string, using the sourceCounter to get a unique string, for each datasource. This is done in line 79 before we finally increment the sourceCounter.

Lastly we need to make this recursive by calling the same function inside itself. We need to change the parameters to make sure we do not get an endless loop. We want all subsites to be aggregated as well, so we call the function with each of the subwebs of the current web:

   88             try

   89             {

   90                 foreach (SPWeb subweb in web.Webs)

   91                 {

   92                     getSubWebItems(ads, ref sourceCounter, aggregateString, subweb);

   93                     subweb.Dispose();

   94                 }

   96             }

   97             catch (Exception)

   98             {

   99                 // Add your own error handling

  100             }

  101         }

Last step of code is to call the getSubWebItems on the OnLoad method, clean up a few things and then add the AggregateDataSource to the DFWP control:

   46             getSubWebItems(ads, ref sourceCounter, aggregateString, web);

   48             aggregateString.AppendLine("");

   50             ads.Aggregate = aggregateString.ToString();

   52             m_dfwp.DataSources.Add(ads);

   55         }

Lines 48-50 finishes the aggregate-string which looked like a collection and adds it to the ads object.

Wow! That’s it. Code is done. Pat yourself on the back. Now comes the easier part, getting this to run and working with our DataFormWebPart.

Now it is time to deploy and add our new component to a page. This has been described many times, including in my blog at http://furuknap.blogspot.com/2008/05/creating-your-own-custom-components-for.html. I’ll skip this now and just head on back to SharePoint Designer to put our component to the test.
In SPD, open the MyTestPage.aspx page and add the Assembly and Register tags as described in my blog article. You should be getting intellisense in code view now:

Click image to open larger screenshot in new window

Complete your custom ASP.net component tag by finding the id-value of the DataFormWebPart you added earlier and putting it in the DataFormWebPartId field of your tag. Add also the ListName of the list you want to aggregate. And, of course, the runat=”server”:

Save, open in browser, et voilá, your subsites’ articles are getting aggregated like there’s no tomorrow:

Click image to open larger screenshot in new window

Now, back to the beauty of this… Give the DataFormWebPart to your designer. Let them make sure this looks exactly as they want it. Sort it, filter it, do what you want, and you will have all the power with a dynamic datasource without the need to constantly update the linked datasource every time you add a new site.

A few things to note:

- This is not scalable code! This component traverses your entire site collection for every hit to the page, which is an expensive operation. You would probably want to either implement some kind of caching or limit which pages are using the component. The point is to show how you can manipulate the datasources, not give you production code.

- Remember to add your assembly to the SafeControls of your web.config, as per http://furuknap.blogspot.com/2008/05/creating-your-own-custom-components-for.html. If you don’t you will get a ‘The control type ‘youcomponent’ is not allowed on this page. The type is not registered as safe.’ error message.

- Remember to reset IIS when you update and redistribute your assembly. Also, SharePoint designer keeps a local cache of your component’s signature, so that if you add or modify properties and you don’t get intellisense, it may be very likely that the local cache is interfering. To remove the cache you need to go to C:\Documents and Settings\[YourUserName]\Local Settings\Application Data\Microsoft\WebsiteCache and clear out items. Don’t worry, you can safely delete everything in this folder, it will get recreated once you reopen a site. Remember to close SPD before you clear it’s cache.

Hey, we’re at the end of the article. Don’t forget to post comments if you have problems or if you just want to give feedback. I’ve also uploaded the completed solution as a zipped Vsual Studio solution for you to use in case you got something wrong.

Attached files for your convenience:

Beginning solution:
dynamicaggregatedatasource_begin1

End solution:
dynamicaggregatedatasource_end1

SharePoint Magazine » datasources

Populating data sources in code