Web Parts

Introduction SharePoint is based on a very rich web interface containing lots of moving parts and lots of customizable areas. As you know the Interwebz is based on a request-response approach where you request a page and get a response back. The approach is the same whether you update the whole page or portions of it. The last decade we’ve seen smart approaches working around this “problem” using DHTML, JavaScript, AJAX, UpdatePanels, you name it. Facebook, which also contains a very rich and dynamic interface, has been excellent in making a dynamic web interface minimizing the amount of data downloaded for each user interaction and in this way also increasing the perceived performance.

The 65th SharePoint Pod Show is out featuring…tada…me :-) The SharePoint Pod Show is THE podcast about SharePoint and is done by Rob Foster, Nick Swan and Brett Lonsdale and has featured a lot of great SharePointers from all around the world throughout the years. If you haven’t already listened to the podcasts, then you got 65 episodes to catch up on! There are some epic ones, such as my favorite one #50 - which is about performance tuning. And make sure that you subscribe - you don’t want to miss their SPC11 Road-trip…

Here goes another post using the WebPartAdderExtension Element. I previously wrote an introduction to custom Web Part Gallery sources and a second one on how to enhance the end-user experience when adding new Web Parts. Now I’m going to show you another trick that this technique can be used for. Introduction Deploying Web Parts are normally done by using the Module element in the Elements manifest and using that element uploading/deploying Web Part Controls Description files (.webpart or .dwp files) into the Web Part catalog. These Element manifests for Web Parts must be scoped to the Site Collection level, since it is there where the Web Part catalog lives (~/site/_catalogs/wp). So if you want do deploy a solution containing a set of Web Parts you need to activate that Feature on each and every Site Collection. You can do it in a number of ways such as Feature Stapling, code, scripting etc. Could be quite tedious work if you have a large farm with many site collections and web applications. Also when retracting solutions with Features that uses Modules we manually have to clean up the files provisioned.

This is a follow-up post on yesterdays introduction to the WebPartAdder (which lately has been one of my favorite features of SharePoint 2010). In that post I mentioned that you could invoke a JavaScript function when a Web Part is added using a custom Web Part Gallery source. The Silverlight Web Part If you have been working with SharePoint as an end-user you’ve probably seen the nice modal dialog that pops up when you’re adding a Silverlight Web Part to a page, see the image to the right. It allows you to very easily configure the Web Part with the appropriate XAP file without editing the Web Part properties. If more Web Parts were like this it would be a whole lot easier working with Web Parts.

Writing this post has been on my agenda for some time, initially I intended to put it into my SharePoint 2010 Web Parts in Action book, but there was not enough time, you know how it is! This is an excellent new feature to SharePoint 2010 which allows you to dynamically populate the Web Part Gallery with Categories and Web Parts. So here we go. Introduction to the Web Part Adder and the Web Part Gallery Think of the List and Libraries category in the Web Part Gallery - it is dynamically populated with the lists and libraries available in the current web. This is all done using the WebPartAdder class which loads all the Web Parts available in the gallery from a number of different sources, see figure below. These source include the List and Libraries category, the local Web Part catalog, files in the wpcatalog, closed and uploaded Web Parts etc.

Recent discussions I’ve been involved with and blog posts have highlighted some of the SharePoint 2010 Sandbox limitations (either as bugs or as a feature). I have also talked about this during SEF 2010 and SPCSEA 2010. While writing my book SharePoint 2010 Web Parts in Action I had the opportunity to discover these limitations early on and have learned to live with it. If you read my book you will find a lot of references to “this does not work in the Sandbox” (you’ve already ordered it huh? Otherwise it’s just one click away).

If you have been working with SharePoint 2010 development using Visual Studio 2010 you have most certainly stumbled upon the new replaceable parameters that replaces data in your solution files during the packaging process. For instance Visual Studio uses $SharePoint.Project.AssemblyFullName$ in the Web Part control description (.webpart) files and this is replaced with the assembly full name (strong name) during packaging. By default it looks like this when you create a new Web Part:

The Tag Profile Page in SharePoint 2010 is used by the Managed Metadata Service (MMS) as a landing page for a term or a keyword. It is used to describe the tag, its location in the taxonomy, synonyms etc. It also contains all the latest tagged items and a note board. The page is quite dull out of the box. Fortunately this page is a Web Part Page and can be customized as you like! You can add Web Parts and rearrange the page. There is not much you can do with the Tag Profile Web Part, but you can edit the Tagged Items Web Part and change how many days it should go back to look for tagged items (default 60 days). The Get Connected Web Part can be slightly configured with what links it will show, see image to the right. And the Noteboard Web Part also has some configuration options such as how many notes to show etc.

I have recently been getting quite a few requests and comments about the status of ChartPart for SharePoint - a charting Web Part that I built about a year ago and shared on Codeplex. This latest version have had more than 6.000 downloads which I think is amazing, version 1 had close to 10.000 downloads. I temporarily put this project on hold a couple of months a go, due to two major reasons; the built-in Chart Web Part in SharePoint 2010 and that I’m currently writing a book (which essentially means that I have no time at all). Now we now that the out-of-the-box charting Web Part is SharePoint 2010 Server Enterprise only and I only have one and half chapters left on the book.

The Sandbox in SharePoint 2010 allows Site Collection administrators to upload solutions in their Site Collections without access to the physical server. This is a great way to open up for creativity and for each Site Collection owner to expand the functionality of their Site Collection without adventuring the stability of the SharePoint farm. Sandbox Solutions do have some limitations, for instance we cannot add new Application Pages. Application pages are normally pages added to the _layouts folder, which are located in the {SharePoint Root}\TEMPLATE\LAYOUTS physical folder on each server.

The CssRegistration class (in Microsoft.SharePoint.WebControls namespace) is one of the most useful controls in SharePoint 2010. It existed in SharePoint 2007 but was fairly limited then. I thought I should guide you through why it is so useful in SharePoint 2010 and why and when you should use it. I briefly mentioned the CssRegistration control in my previous post on SharePoint 2010 themable CSS files. But first some background. Why the CssRegistration control? There are plenty of times when you need to add custom CSS definitions to your SharePoint projects, for instance in pages and Web Parts. There are several methods of adding CSSes to your projects. You could use inline CSS styles - which results in a lot of markup which may slow your page/site down. Another approach is creating a CSS file and include it in your master page - better but the CSS is always loaded.

SharePoint 2010 has a completely rebuilt theme engine. Instead of having to modify .inf files, create folders and copy and pasting CSS files and images in the SharePoint root we can now create a theme in PowerPoint and upload it to the server. The default SharePoint CSS files are tagged with comments that tells SharePoint to substitute colors and images with the values from the theme. When you switch theme SharePoint generates a new set of CSS files and images with the result of this substation.

While I was testing building some mashups using SharePoint 2010, Web Parts and SharePoint Designer I found an interesting bug. Initial problem Here’s what I did; I set up a Wiki Content Page (the new kind of Web Part Pages) in SharePoint 2010 that was supposed to be called with Query String parameter named ID which should be used by a Web Part. Another page contained items linking to this page using different integer values for the ID query string parameter like this:

The SharePoint 2010 Development Tools for Visual Studio 2010 is great and I really like the way that the project is built using the different artifacts. One thing really annoys me though and that is the way that the code is generated and named when you add items. For example if you create a project and then add a Web Part item to that project then Visual Studio will create a Web Part class with a namespace and class name like this:

SharePoint is an amazing product and there are some fantastic opportunities to make awesome applications. It also has a great API which has had improved further in the upcoming SharePoint 2010 release. But there are several features available in the platform/API that just isn’t available to all of us, unless we sit in Redmond and are building the actual product. There are so many classes or methods that are marked internal or sealed, that I really would like to use. I’m not going to nag about the search Web Parts this time, but instead focus on some classes that I really would like to be changed from internal to public.

This is the second post in my mini series on how to extend the SharePoint 2010 Ribbon. First post can be found here. The goal with this excersice is to extend the Editing Tools Insert tab with a smaller Insert Web Part drop-down, so we don’t have to expand the whole Web Part Gallery to insert a Web Part. In the last post we created a Visual Studio 2010 solution and added the drop-down to the correct tab in the Ribbon using the CustomAction element and some new SharePoint 2010 XML syntax.

SharePoint 2010 contains numerous of improvements in the user interface and it has been built to be able to be extended. I guess that all of you have seen the Ribbon in SharePoint 2010 by now and probably even tried to add a button and fire away a Hello World JavaScript alert (it’s one of the HOLs available also). That’s quite an easy task. But doing some more advanced contextual and dynamic customizations to the Ribbon really makes you sweat!

This is the first post for the year of 2010 and what could be better to start with than announcing that I’m writing a SharePoint 2010 book. More specifically I’m writing a book about SharePoint 2010 Web Parts development with the working title SharePoint 2010 Web Parts in Action. This is a dream come true to me and I have been thinking about writing a book on and off for quite some time. I want to take my writing/blogging even further, it’s through writing that I educate and evolve myself. It makes me think twice and really make sure that I’m writing the correct stuff (who wants to be haunted down by all the readers and pros out there :-). So a book will be perfect to learn more about the SharePoint 2010 platform and dig down even further in Web Parts development.

Visual Web Parts are a nice addition for SharePoint 2010 developers. A Visual Web Part is essentially SmartPart revisited and is one of the project types of the new SharePoint extensions for Visual Studio 2010. Sandboxing is one of the most interesting features of SharePoint 2010, especially for large scale implementations and hosting providers. The Sandboxing feature, or User Code Solution, allows you to easily upload a SharePoint feature into your farm into a special controlled environment – called a Sandbox. These Sandboxed features can be controlled by the SharePoint administrators so that they do not consume to much resources and automatically disable them if the exceed their limits. Sandboxed solutions also have severe security restrictions – you cannot access all objects or resources that you would like.

Inspired by the latest SharePoint PodShow topic; The SharePoint Data View Web Part-Episode 31 and Laura Rogers post on building a permissions dashboard I just had to write this post. In the last paragraph Laura quickly mentions how you can reuse the created Data View Web Part. I think this is really important to know how to export and import this Web Part. What I don’t want people to do is to fire up SharePoint Designer and create these Data View Web Parts in the production environment so that the pages get’s unghosted or customized. Also when you are working with solutions packages and features to deploy your applications in environments it’s necessary to know how to do this.

This is the first post in a series on Web Parts Connections. This spring I had a series on Web Part Properties that I think was very successful, they got some good comments and feedback and they get a lot of hits from search engines. Please help me out and evolve this new series of posts with some feedback and questions. What is Web Parts Connections? Web Parts Connections allows you to connect the Web Part server controls so that they can exchange information. Web Parts can either be a consumer and/or a provider. Once you connect a consumer with a provider the consumer starts receiving data from the provider, all this is done on the server side. Web Parts can be constructed in such way that it can have several consumer and provider connection-points, i.e.it can consume or provide information from several different sources. A provider connection-point can have several consumers but a consumer connection-point can have only one provider.

I’m glad to announce that I finally got my stuff together and stitched together the last pieces of the beta of ChartPart for SharePoint 2.0. ChartPart for SharePoint is a SharePoint Web Part that allows you to draw charts from existing SharePoint lists. It’s available at CodePlex, at http://chartpart.codeplex.com/, and is free for use. ChartPart 1.0 have had over 4.000 downloads since it was released and is translated to six different languages. The first version was pretty limited in customization and you could only create some basic charts.

I have been answering questions on the SharePoint forums at MSDN Forums, and while some are really tricky and interesting, some are really basic beginner mistakes. A couple of questions lately have been about Web Part development and how to and where to create your controls. Most of these is easily solved if you understand how the Web Part event model works. First of all you need basic ASP.NET understanding and know how the Page and Control objects work together, how a postback works etc. But I have even seen somewhat experienced ASP.NET developers failing at this point, probably due to the fact that Visual Studio have a slick interface for editing user controls and ASP.NET pages. When it comes to SharePoint you have no visual aids and you are out on thin water, and this knowledge is crucial.

A Web Part, in SharePoint or not, has a Verb that allows the Web Part to be Closed. Closed means that the Web Part is just closed (not rendered) and not deleted, which is a separate Web Part Verb. Closing Web Parts can cause headache for your users and even a really bad performance. Note: To delete a Web Part you have to go in to Edit mode for the page. Close can be done directly from the Web Part menu.

To end my series of Web Part properties I would like to show how to store more complex values than just strings or integers. What happens if you would like to store a more complex object; an array or a coordinate etc? Editing these properties with the standard generated interface using the WebBrowsable and Personalizable attributes will not work, since it only accepts basic types, shown in part 1. To make these properties editable you have to (almost…continue reading) create an EditorPart, shown in part 2, and control the properties in the SyncChanges and ApplyChanges methods.

If you are building a reusable web part that you would like to sell or give away you should look into localizing your web part. The localization support is great with .NET 2.0, using resource files, and there are tons of built-in functionality for this. If you are creating an Editor Part for you web part, then your life is pretty easy, just use the standard techniques. But if you are using the approach by tagging the properties of your web part with the Personalizable attributes, then you are out of luck. Take a look at this property for example:

Part four of my Web Part Properties series. Now it’s time for default values and what you should do when there are values that are incorrect or missing . Last post discussed the .webpart file and I showed you how to do when setting up a Web Part in the Web Part Gallery with default values. Web Parts created using the SharePoint WebPart class can also define default values using the DefaultValue attribute, like this:

This is the third part of my Web Part Properties series and this post will focus on the .webpart file. Every SharePoint developer have seen it and perhaps edited it, but what is the purpose of the file and when and why should I edit it. Background The .webpart file is an XML file containing metadata about the Web Part. In previous versions of SharePoint this file had an extension of .dwp. Although these files may look similar it’s a crucial difference between those files. The .webpart file uses the http://schemas.microsoft.com/WebPart/v3 schema and the .dws file uses http://schemas.microsoft.com/WebPart/v2. The v2 schema is intended for Web Parts derived from the Microsoft.SharePoint.WebPartPages.WebPart class, which is the base class used for developing Web Parts for previous SharePoint versions. When developing Web Parts using the .NET 2.0 WebPart class (System.Web.UI.WebControls.WebParts.WebPart) the v3 schema must be used, see previous article on why you should use the latter.

This is the second part of the Web Part Properties series. The last post walked through the basics on how to make editable properties on a Web Part. As a sample I used a Web Part that displayed tweets from Twitter - called TweetPart. Using the standard approach, by marking the properties using specific attributes, we made the Web Part editable as we wanted. But the user experience, for editing, was not optimal. First of all the properties we wanted to edit was located in their own category at the bottom, not that easy to find for inexperienced/untrained users. Secondly the properties has dependencies and requires validation.

I thought that I should kick off this new year with a series of posts on how to make your SharePoint Web Parts editable and how to enhance that out-of-the-box Web Part property editing combined with some tips and tricks. This first post may be to most of you SharePoint developers somewhat basic, but I have chosen to start from scratch here. Many of this first post topics are repeatedly asked in the MSDN development forums. The documentation in the SharePoint SDK on this topic is really bad; it just says do this and do that, never why you should do it. Often this makes developers unaware of pitfalls or possibilities.

When working with SharePoint Web Parts and features it is easy to get into trouble if you are changing the version of your Web Part DLL file. The easiest way to get around this is to never change the version of the Web Part, which is a pretty common scenario. But if you are developing a product or feature that you expect to have a longer life cycle and that you will upgrade or enhance over time you should really use the assembly version features. Having a version on your Web Part will make it easier for you to support it for multiple customers and/or installations.