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.

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.

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 (.

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.

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.

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?

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!

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).

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 .

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.

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.

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.