SharePoint Web Part Development - Solutions for 2 Common "Gotcha's"

SharePoint and Web Parts : An Introduction

Microsoft SharePoint is clearly the current top-dog in corporate information sharing, document management, and workflow management. What many companies are now discovering is how SharePoint can be an effective tool in displaying and monitoring key business and technology performance indicators. This can be easily accomplished in SharePoint due to its compelling ability to create a SharePoint dashboard (in SharePoint jargon known affectionately as web part pages), which are custom SharePoint pages which are populated with either out-of-the-box, Microsoft provided web parts, or increasingly, custom web parts created by developers. These web parts can then be configured to visually display up-to-the-minute visualizations of information from various corporate databases, as well as from other web services.

The rise of dashboarding coupled with Microsoft’s commitment to improving the SharePoint development experience by creating progressively more effective API’s with increasingly tight Visual Studio integration has been steadily driving the development market for SharePoint. In SharePoint 2010 the first type of custom web part a developer is exposed to is typically the “Visual Web Part”. Developing a visual web part is akin to developing an ASP.NET “Web User Control”, and is usually quite easy for most seasoned ASP.NET developers to pick up on.

Gotcha #1 : Customizable Web Parts

Usually the first question asked by developers once developing a couple of web parts is “How do I allow for users to easily customize my web part?” Well, there are essentially 3 ways:

1. Store the customizable configuration parameters in the web.config file for SharePoint - Now, this is entirely functional, but it is not very convenient for users to be editing the web.config file (nor is it recommended for obvious security and safety reasons), so this is not recommended for any configuration item which anyone other than a system administrator would be changing.
2. Add HTML controls which allow for configuration - While this is easy to implement, leaving a lot of HTML controls on your web part takes up valuable screen real estate, and interferes with what I believe is the primary purpose of any web part, to display information is the easiest possible way for human consumption. So with that, you must be asking yourself, “Well, then what is the preferred way?”
3. Use SharePoint configuration panel - The best practice for allowing user customization of your web part easily and safely, without taking up screen real estate, is using the native SharePoint web part properties configuration panel. SharePoint has a built-in mechanism allowing for the configuration of properties which developers can integrate in to their web parts, and thankfully it’s easy to use.

Let’s walk through the creation of a configurable property in the SharePoint configuration panel. Say we had a web part named “WebPartPropDemo”, and that we needed the ability to configure a parameter named “Error Threshold.” We could add this configurable property to the SharePoint panel by adding the following code to the WebPartPropDemo.cs file (note: NOT the same as the WebPartPropDemo.ascx.cs file):

[WebBrowsable(true), Category("Configuration"), 
Personalizable(PersonalizationScope.Shared),
DefaultValue(0), WebDisplayName("Error Threshold"), 
WebDescription("Error cutoff threshold")]

public int ErrorCutoff
{
	get { return _nErrorCutoff; }
	set { _nErrorCutoff = value; }
}
public static int _nErrorCutoff;

Upon inspection you can see that there is even the ability to set a default value as well as create user-friendly names and descriptions for the configurable property. To access the configured value is easy as cake (I say this preferring cake over pie), from inside the actual web part code-behind we can access the value of the property with the following simple code:

int a = WebPartPropDemo._nErrorCutoff;

That’s all there is to it! You don’t even have to worry about persisting the configured property value; SharePoint does it for you by storing it in one of its databases. Thus with visual web parts, customization is easy.

User Interactivity and Silverlight

With all this talk of customization the next question which naturally arises is what about web part interactivity? While some of my HTML and JavaScript guru friends may take issue with this slightly, there really is only so much interactivity which can be accomplished through HTML. To achieve real, meaningful interaction, traditionally full applications were needed. However with the advent of Silverlight applications (which are akin, yet superior to the older Java applet), it is possible to achieve nearly infinite user interactivity. For a brief demonstration of some of the interactivity possible with Silverlight check out our Silverlight demonstration (NOTE: Inactive).

Most importantly, Silverlight has broad OS and browser support. Silverlight is supported by IE, Firefox (on Windows and MacOSX), Safari (on Windows and MacOSX), and even has a Microsoft-supported open source port to Linux named Moonlight. Silverlight provides a feature rich API which rivals or exceeds traditional Windows applications, however the details of the API are beyond the scope of this article but can be further explored at:

http://www.microsoft.com/silverlight/

Silverlight applications can be embedded into any and all web pages independent of server-side scripting paradigm (PHP, ASP.NET, JSP, etc.). Due to the success of Silverlight, integration with SharePoint was expected, and with the release of SharePoint 2010 a new out-of-the-box web part appeared, the Silverlight Web Part. The Silverlight web part allows for the embedding of Silverlight applications as web parts into a dashboard. Besides the fact that Silverlight allows for epic customization, another benefit to using Silverlight applications is re-use. Unlike visual web parts for SharePoint, Silverlight applications can be used on corporate web sites, intranet sites, as well as SharePoint portals, the re-usability of Silverlight applications can lead to significantly higher return on investment.

You can also check out Rick Rietz's blog to learn more about the benefits of creating business applications with Silverlight.

Gotcha #2 : Silverlight and Data Access, A Web Service Solution

This makes things a no brainer for development right? Silverlight applications are the same as a visual web parts, yet can do more, so it’s easier right? Of course, with all computer technologies, the answer is not as simple as we would like. While some aspects of Silverlight are far easier, one thorny issue usually rears its ugly head first, data access. SharePoint visual web parts execute and render HTML on the IIS Server which hosts the SharePoint web application and can connect directly to any SQL Server (or other database server flavor) which is accessible from the server, whereas Silverlight applications are downloaded via HTTP and actually execute on the client computer and have no access to any database server. In order to access data, Silverlight applications must access the data via a Windows Communication Foundation service, or a traditional web service.

WCF services are the new standard bearer for communication, however, they are more difficult to implement and a little more difficult to integrate with SharePoint. For most cases an old-fashioned web service does the job just fine, and fortunately for developers, they are easy to integrate into SharePoint, and run on the same IIS server! The steps to create and integrate a web service in SharePoint 2010 are as follows:

1. Create a web service which accesses data from the database server of interest. (Beyond the scope of this article, but can be explored at: Microsoft MSDN
2. Compile
3. Copy the ASMX and web.config files for the service into the following directory (which is easily accessed with IIS Server Manager): SERVER\SHAREPOINT WEBSITE\_layouts\{web service name}
4. Copy the compiled DLL for the web service into: SERVER\SHAREPOINT WEBSITE\_bin\
5. Now you can access your newly installed web service at the following URL: http://{web server name}/_layouts/{web service name}/{web service name}.asmx

Voila! You now have a web service, hosted within SharePoint, which is accessible from a Silverlight application (or any other type of application) that will enable your Silverlight applications to access any and all data which you want them to have access to.

Final Thoughts

I hope this brief introduction to web part development in SharePoint was informative and enjoyable, and I hope that the solutions presented for two common “gotcha’s” of SharePoint development presented here help you on your way to understanding and developing rich SharePoint web parts with and without Silverlight. We here at DMC are experts with SharePoint and Microsoft technologies, and would love to help you implement whatever solution your business needs.

Until next time, you stay classy Chicago.

Learn more about DMC's SharePoint consulting services.