Instead of drilling down into all of the Web Parts, we’ll describe the relationship between Web Parts and lists, which seems to be a common point of confusion. Most people, having played with WSS or MOSS for some time, have a tendency to ask why the number of Web Parts keeps changing.

When opening the Add Web Parts dialog, as in Figure 25-1, on an ordinary Web Part page, we will typically see the Lists and Libraries grouping. This grouping represents every single list and library that exists within the site and is currently visible to users (besides permissions, there is also a Hidden property for each list).

The list of Web Parts within the lists and libraries expands and contracts when new lists and libraries are added to or deleted from the site. Simply speaking, whenever a new list is added, a new ListViewWebPart Web Part is added with the same name as the added list, with a predetermined view, depending on the type of list created. In other words, each list view you create in SharePoint is actually an instance of a fundamental Web Part that is built into the MOSS framework—namely, the ListViewWebPart.

Figure 25-1. Add Web Parts dialog

Building on the core Web Parts that were described in Chapter 8, we will add all of the remaining Web Parts that belong both in the WSS code base and in MOSS. For more details on the use of some of these Web Parts, consult their associated chapters. To maintain consistency, the Web Parts are listed in the same sections as they are organized in the catalog.

Additionally, the majority of the Web Parts listed in the following tables are available only with MOSS, and not with WSS. Web Parts for lists and libraries, as well as Web Parts in the Default and Miscellaneous sections, are provided with WSS. There are also other Microsoft Web Parts that integrate the SharePoint platform with other products (such as Project Server or Reporting Services Integration), and they either ship directly with the product or are available for download from the Microsoft Download site. Table 25-1 lists the Business Data Web Parts.

Business Data Web Parts are utilized in conjunction with the Business Data Catalog, and require additional configuration of entities and actions within the BDC. Business Data Catalog is available with the Enterprise version of MOSS.

Table 25-2 lists the Content Rollup Web Part.

Site Aggregator, as seen in Figure 25-2, is typically used on a My Site to show a particular user bits and pieces of other sites that are specifically relevant to the user. Other forms of aggregators can be achieved via RSS aggregators, custom queries, and a number of third-party Web Parts.

Figure 25-2. Site Aggregator

Table 25-3 lists the Dashboard Web Parts.

Dashboard Web Parts, as seen in Figure 25-3, should be used instead of the default List View Web Parts whenever KPI lists are involved. These Web Parts provide rich interaction with KPI data sources and data as well as a very slick display. They are always a great hit during a demo, and are relatively easy to configure. KPI Web Parts and KPI lists are available only with a MOSS Enterprise license.

Figure 25-3. Dashboard Web Parts

Default Web Parts are used on a typical collaboration portal and help organize some simple content that is not available via other parts (Table 25-4). These Web Parts, along with some of the Miscellaneous Web Parts, allow for creation of complex portal content and navigation without the need for any other tools.

Filter Web Parts are a staple of interactive Web Part pages, allowing the designer to relate one piece of data to another (Table 25-5). With a growing number of Web Parts supporting Web Part connections, the filters provide a very simple way of producing a variety of relationships on the pages. There are three types of Filter Connections: Automatic, User, and List-based, which support a variety of Data Types, from simple Text all the way to multiple values in a list.

Whereas the List View and Filter Web Parts provide designers the ability to display and glue content that is available on the site, the Miscellaneous Web Parts (Table 25-6) provide the ability to fill in the gaps with some interstitial content as well as external XML or web-based content.

Outlook Web Parts allow the use of Outlook Web Access (OWA) elements directly within the SharePoint portal, usually within My Site pages (Table 25-7). When the Outlook Web Access URL is populated in the profile, the user sees the My OWA button.

Search Web Parts (Table 25-8) make up their own ecosystem, tailored specifically to serving search results, as seen in Figure 25-4. Overall, they are very flexible and provide a great degree of customization. There are more Web Parts available when the Knowledge NETwork components of SharePoint are installed. For more information, follow the KN blog at http://blogs.msdn.com/kn.

Figure 25-4. Search Web Parts on a Search Results page

Site Directory Web Parts provide an enhanced way of navigating through sites without the use of tabs or the lefthand-side tree structure (Table 25-9).

There can be a number of files associated with Web Parts, including a Web Part configuration file, an assembly, a registration for the web.config file, and occasionally additional resource files or policy settings.

Web Part XML configuration files are either .dwp files, representing the SharePoint 2003–style Web Parts, or .webpart files, representing the ASP.NET 2.0–style Web Parts. These files would typically be used as part of a site definition, as part of a Web Part Catalog (this is a wpcatalog folder underneath your web application root directory), uploaded to a Web Part library, or simply imported onto a page.

Next, the Web Part assemblies are the code compiled into a .dll file. Web Part assemblies may have some additional files associated with them, depending on the type of development performed. The .dll files will typically be installed into the web site’s /bin directory (e.g., C:InetpubwwwrootwssVirtualDirectories81in for a web application installed on port 81), or to the global assembly cache (GAC), which is located in the C:WINDOWSassembly directory, as seen in Figure 25-5. Assemblies that are deployed to the GAC are available to all applications running on the server, and require execution with full trust privileges. Deployment of assemblies into a bin directory typically allows for easier manual deployments than into GAC, and requires only partial trust security. Commonly, assemblies deployed into GAC may be locked by the application server, and may require an artificial stop of the application in order for these assemblies to be released.

Each Web Part assembly also needs to be properly registered within the web.config file, and, if necessary, a Code Access Security (CAS) policy must be created. The web.config file holds Web Part registrations in the SafeControls section, with each Web Part or assembly registered as a SafeControl entry. Each element has the following attributes:

Without the SafeControl entry, an assembly used by the Web Part simply cannot be used within MOSS. Here is a sample entry that is actually used later in this chapter:

	<SafeControl Assembly="HelloMOSS, Version=1.0.0.0, Culture=neutral,
	PublicKeyToken=9f4da00116c38ec5" Namespace="HelloMOSS" TypeName="HelloMOSS"
	Safe="True" />

The security policy is defined in the web.config file as well. There are two entries, one where it is declared SecurityPolicy and another where it is actually used, called trust.

	<trust level="Full" originUrl="" />

Last, there are external resource files associated with the Web Parts (resources can also be embedded inside the assemblies). These are resources such as JavaScript files, images, and some other common elements that can be utilized at the client side. There are two potential locations where the extra resource files can be placed (Table 25-10); one of them is highlighted in Figure 25-6.

Figure 25-6. Web Part resources

Additionally, a Web Part may rely on some other piece of MOSS infrastructure and contain references to some modules, lists, or controls. These other elements would be placed in some other appropriate directory dedicated to site definitions, modules, or user controls. Web Parts that carry dependencies on other parts of MOSS are typically bundled in .wsp files that define a full solution. In other words, if you are packaging a Web Part that acts as the center point of a particular page layout, you will package the full page definition with the Web Part. When the package is deployed and activated, users will see the custom Web Part and any of the additionally packaged assets.

There are a number of techniques and tools that can be used to install Web Parts in WSS and MOSS, listed in Table 25-11, ranging from a number of manual steps to full-blown MSI installers. Most of these approaches take pretty good care of the work behind the scenes, and typically deploy files into correct locations and update the web.config for the correct web application.

	stsadm -o addsolution -filename filename.wsp
	stsadm -o deploysolution -name packagename" -local -
	allowGacDeployment -url urlname
	stsadm -o activatefeature -id featureid -url urlname

There are a few things that an administrator has to be prepared for to support MOSS. Unfortunately, babysitting Web Parts may be one of the necessary duties. There can be many potential problems associated with the execution of Web Parts:

The top toolbar shows whether you are using a personal or shared view, and the grid below displays all of the Web Parts, along with their type and status on the page. By selecting the checkbox and clicking Reset or Delete, you can easily control a misbehaving Web Part:

Web Parts expose a number of properties that allow their simple configuration (Table 25-12). Although each Web Part can expose a number of custom properties directly in the configuration pane, as well as custom configuration sections, the built-in infrastructure provides three configuration panels for Appearance, Layout, and Advanced properties.

A more specialized element of configuration is the ability for Web Parts to connect with one another. Unlike other properties set within the Web Part property pages, connectivity is configured via an action tied to the title menu. Using Web Part connectivity is a great way to create dynamic web-based applications without necessarily using any development tools. Sample Web Part Connectivity is shown in Figure 25-9.

After a page or a Web Part is taken into an Edit Mode, you can click the Edit button, and expand the Connections submenu. Depending on the type of connectivity exposed by the Web Part, and on the availability of other Web Parts on the page, typically you will be able to see some choices from which to select. For instance, the Data View Web Part, as seen in the example, allows the use of Provide Row data, Provide Data, and Get Sort/Filter. After selecting one of the active items, you will see a choice of Web Parts that are capable of accepting a connection. If the choices are grayed out or inactive, there are no Web Parts on the page capable of accepting a connection. Different Web Parts will provide different connections and accept different data. Not all data types can be passed in a connection.

Figure 25-9. Web Part Connection

Additionally, Web Part connections can be configured in SharePoint Designer. Although use of SharePoint Designer “unghosts” the Web Part pages, it also allows greater flexibility in terms of Web Part connectivity. Whereas autogenerated connectivity between Web Parts created with the browser UI typically creates ugly radio buttons, SharePoint Designer allow you to create connections based on images, links, or other HTML elements.

Web Part connectivity also depends on the interface implemented by the Web Part, as well as availability of Web Parts that implement a complimentary interface. For the older style Web Parts, not only do you need a provider and a receiver, but you also need compatible interfaces. For the new WSS 3.0 Web Parts, communication is performed via a shared interface, and registration of this interface in two Web Parts is via ASP.NET attributes. Specific interfaces used to cover Web Part connectivity are covered later in the “Advance Web Part Development” section.

Thus far, we have mainly dealt with existing Web Parts; for the remainder of this chapter, we will deal with creation of new Web Parts. Developing Web Parts requires a development environment.

Perhaps one of the weakest experiences with MOSS is that of the casual developer. Many user group meetings and conferences are filled with water cooler talk focused on configuration of the development environment (Table 25-13). Simply speaking, for the very best environment you will need to develop directly on the server. If you install all elements in a standalone environment (MOSS, SQL 2005, or Visual Studio 2005), you will get simplified deployment and debugging that you would not be able to achieve otherwise. Once you have built and tested your Web Part, you can package it and deploy it on your multiserver farm as part of a scheduled production release.

There are also some external components in a typical environment, such as email and the domain server. They are definitely not required, but still nice to have from an infrastructure perspective. Visual Studio 2005 is certainly not a requirement for Web Part or SharePoint development, but it does make a few things easier. You would need some kind of an editor (Notepad) and .NET SDK to compile the code.

Web Parts in MOSS 2007 have 2 distinct flavors, depending on whether the older or newer API is used. The older API is derived from legacy SharePoint 2003 technology (aka the Microsoft.SharePoint namespace), and since the Web Part technology has now been included directly in Windows, the new API is based on Microsoft ASP.NET 2.0. The new Web Parts are now a part of the System.Web.UI.WebControls.WebParts namespace.

A typical approach to Web Part development and deployment is similar, regardless of whether the developer starts with a simple class project or with Visual Studio 2005 Extensions for WSS. The main difference would potentially lie in the deployment approach, where the developer can choose the xcopy deployment instead of the msp package automatically built by the Visual Studio. Actually, a majority of the Web Part’s inner workings are identical to that of an ASP.NET Server Control. For a simple Web Part, the process looks as follows:

Visual Studio 2005 Extensions for WSS provide a collection of tools and project templates that create simple starting point for development of Web Part–style projects. Literally, the Web Part template provides sufficient code for the simplest Web Part and for its deployment with a simple F5 click. This code, as well as some additional plumbing steps, would work as a standard “Hello World” sample.

	using System.Runtime.InteropServices;
	using System.Web.UI;
	using System.Web.UI.WebControls.WebParts;

	namespace SimpleWebPart
	{
	    [Guid("25ed441d-9c4a-4892-8a71-99edc1f2a1d2")]
	    public class SimpleWebPart : WebPart
	    {
	        protected override void Render(HtmlTextWriter writer)
	        {
	            writer.Write("Hello to Bob from Piotr");
	        }
	    }
	}

The following steps create a simple “Hello MOSS” Web Part in Visual Studio 2005, with Visual Studio 2005 Extensions for WSS on a development machine with MOSS 2007 installed on the default port 80:

Behind the scenes

The magic of hitting F5 in Visual Studio takes care of a number of other steps that you would otherwise have to handle manually. Later on, we’ll develop a simple Web Part without using any tools, but it is equally important to know what the tools have done.

Besides the necessary template files, the Web Part project has some other settings (some of them are editable from the Project Properties page, in the SharePoint Solution section). Basically, it allows automated deployment of Web Parts into a local server.

First, you should look at the directories where the project was created and built. In our example, this was the C:ProjectsCh25HelloMOSS directory, which contains the Visual Studio solution file. The DEBUG build directory and the code are under-neath in the C:ProjectsCh25HelloMOSSHelloMOSSinDebug directory, as seen in Figure 25-16. There are several files that are of significant interest to us:

• HelloMOSS.wsp

• Setup.bat

• Solution directory

  

  Figure 25-16. Project Debug directory

These files are created by the Web Part project template. HelloMOSS.wsp is the deployment package, and the setup.bat is the command prompt setup utility that interacts with MOSS via the stsadm utility and takes care of Adding, Deploying, and Activating the solution (as well as subsequent uninstallation steps). You can also see that there is a solution directory, which actually represents the internal contents of the HelloMOSS.wsp file. There are a couple of XML files, our Web Part assembly, and the .webpart file. If you look at the manifest.xml and feature.xml files, you will notice that they represent a unique solution file, and similarly a unique feature, where the feature ID is tied to the GUID attribute of the HelloMOSS class, as declared in the project (also visible in Figure 25-16).

The next element that may be of interest is the setup.bat file, which manages the registration of the assembly within the server. Using the command prompt, as seen in Figure 25-17, we open the location of the setup.bat file and execute setup -? to look at the available options. Using this tool, you can control solution installation and uninstallation as well as the activation and deployment of the solution to a particular site collection of your choice. This provides a decent level of flexibility, as it may be tedious to open so many sites to activate a feature.

Figure 25-17. Command prompt options of setup.bat

Since the setup.bat tool was used, next we can look at how and where the files included in the solution were deployed. Based on previous experience, we know these can be deployed to the GAC or to the bin directory, and additionally, we know that these are deployed as full-blown features.

First, we can look at the Site Collection’s set of features. I used the setup.bat tool to activate the feature in another site collection (e.g., http://localhost/sites/collab). Now, to open the site:

1. Click the Site Actions drop-down list.

2. Click Site Settings (and optionally All Site Settings, depending on the template).

3. In the Site Collection Administration section, click Site Collection Features. (Note that there is also a Site Features button, which is tied into a web and not into a site collection.)

4. The Site Collection Features page (as seen in Figure 25-18) shows a HelloMOSS feature that is already activated.

5. Going back to the Site Settings page, click the Web Parts link in the Galleries section.

   

   Figure 25-18. Site Collection Features

6. The Web Part Gallery page shows an entry for the HelloMOSS.webpart; you can click the name of the Web Part to see its preview. You can also click the Edit icon to modify the Web Part Properties, as seen in Figure 25-19.

Next, we can verify that the Web Part has been deployed to the GAC (which implies it was deployed globally) and check its registration in the web.config file. To navigate to the GAC, simply open Windows Explorer and open c:WINDOWSassembly, where c:WINDOWS represents the place where your OS has been installed by default, as seen in Figure 25-20.

Finally, we validate the SafeControls section inside the web.config file (Figure 25-21), which, by default, exists in the c:inetpubwwwroot directory. Our Web Part’s registration is shown in the following line:

	<SafeControl Assembly="HelloMOSS, Version=1.0.0.0, Culture=neutral,
	PublicKeyToken=9f4da00116c38ec5" Namespace="HelloMOSS" TypeName="HelloMOSS"
	Safe="True" />

Obviously, if you are not working with the Visual Studio 2005 Extensions, you will have to complete all of the behind-the-scenes work yourself. Typically, there are a few more steps before the code shown earlier becomes a real Hello World–style Web Part on a page. To develop a simple Web Part from scratch, you will most likely follow these steps:

Figure 25-19. Web Part Gallery displaying properties of a Web Part

Figure 25-20. HelloMOSS inside GAC

Examples in the previous sections have shown all of the necessary steps to develop a Web Part. For hardcore ASP.NET developers, this is probably very familiar, as it is similar to the development of Server Controls.

Table 25-14 lists common Web Part samples and tricks.

	SPWeb cWeb = SPControl.GetContextWeb(Context);
	Type cType = BaseWebPart.GetType();
	string classPath = SPWebPartManager.
	GetClassResourcePath(ccWeb, ccType);

	string filePath = Page.ClientScript.GetWebResourceUrl(this.
	GetType(), "AssemblyName.folder.filenname.gif");