Web Part Properties

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.