About Web Parts

A Web Part is is a modular unit of information that has a single purpose and that forms the basic building block of a Web Part Page. A Web Part is actually composed of two basic files, often requires additional resource files, and its property values are stored in database tables. Understanding how Web Parts work can help you share them in more creative and interesting ways and avoid problems.

The following diagram summarizes the design of Web Parts, using the Image Web Part as an example.

1 The Image Web Part description file (.dwp) is a portable container of default and personalized property values for the Image Web Part.

2 The Image Web Part assembly file (.dll) contains the logic and code for the Image Web Part, and is installed on a site server.

3 Resource files that support the Image Web Part are also stored on the site server.

4 Tables in the Windows SharePoint Services database are used to store current values of the Image Web Part properties.

There are two important concepts to understand about the way Web Parts have been designed:

There is one Web Part assembly file, but there may be several instances of the Web Part used at your site (or even at other sites). Each instance of a specific Web Part may be similar or different in appearance and behavior, but it is based on the same Web Part assembly file installed on the site server. There can also be code for more than one Web Part in a Web Part assembly file.
For a Web Part to work properly, you must have both files, as well as any additional resource files, available to you at your site. This is usually not an issue for Web Parts that are built in to Microsoft Windows SharePoint Services, but can be an issue for a Web Part obtained from another site or source.

A Web Part description file is an XML text file with the extension .dwp. It can contain the following:

Property names and settings for the instance of this Web Part.
A reference to its companion Web Part assembly file (.dll).
If a user has personalized a Web Part, changes to any common and custom property settings.

For example, here is the Web Part description file for the Image Web Part:

<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://schemas.microsoft.com/WebPart/v2"> (1)
  <Title>Image Web Part</Title>
  <FrameType>Default</FrameType>
  <Description>Use to display pictures and photos.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>LeftColumn</ZoneID>
  <PartOrder>1</PartOrder>
  <FrameState>Normal</FrameState>
  <Height /> (2)
  <Width />
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <IsVisible>true</IsVisible>
  <DetailLink />
  <HelpLink />
  <Dir>Default</Dir>
  <PartImageSmall />
  <MissingAssembly />
  <PartImageLarge>/_layouts/images/msimagel.gif</PartImageLarge> (3)
  <IsIncludedFilter />
  <Assembly>Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, 
     PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>
    Microsoft.SharePoint.WebPartPages.ImageWebPart
</TypeName>
</WebPart> (1)

1 The WebPart element identifies this XML code as a Web Part description file and contains the remaining elements in the file.

2 If the property value is blank, the Web Part uses the default values stored in the database tables.

3 I f the property value is not blank, the Web Part overrides the default value and uses the new value for this instance of the Web Part.

When Windows SharePoint Services is first installed, a Web Part description file is often stored in the Site Web Part Gallery. Other instances of this Web Part description file are created over time as users export Web Parts, and as site administrators upload and download Web Parts.

The Web Part assembly file is an ASP.NET Dynamic Link Library file (.dll) that contains the logic and code of the Web Part. It is a companion file to the Web Part description file. However, for all instances of a particular Web Part on a site, there is only one assembly file. This assembly file contains managed code that derives from an ASP.NET Web Form Control (def). Managed code is essential to make the Web Part work because a Web Part Page is an ASP.NET Web page (.aspx).

When Windows SharePoint Services is installed, the Web Part assembly file for each Web Part is installed on the site server. Over time, additional custom Web Parts may be installed by the site administrator. In addition, any resource files required by the Web Part, such as images, alternate language files, and other auxiliary files, are installed in system folders on the site server. To ensure that a Web Part is safe, it must registered by the site administrator as a safe control.

Each Web Part shares a set of common properties (also called base class properties) organized into sections in the tool pane that control its appearance (such as the title, height and width), layout (such as the Web Part order in the zone and the direction of the content), and advanced characteristics (such as the image icon and description).

Many Web Parts also have custom properties that are unique to the Web Part. These are usually displayed either above or below the common Web Part properties in the tool pane. For example, the Image Web Part has additional custom properties, including the image link, it's horizontal and vertical alignment, and background color.

Note Depending on how the Web Part was created, in some cases a Web Part custom property may be displayed in a default Miscellaneous section below the common properties in the tool pane.

An instance of a Web Part can be classified as one of three types:

Shared Web Part A Web Part added to a Web Part Page by a user who is creating or making changes to the Web Part Page in shared view. Shared Web Parts are available to all users of a Web Part Page with appropriate permission.

Personalized Web Part A shared Web Part with one or more property values modified by a user who has made changes to the Web Part in personal view. The changes made to the personalized Web Part are only available to the user who made those changes. However, other users who did not make changes in personal view continue to see the shared Web Part.

Private Web Part A Web Part that a user has added to a Web Part Page from a Web Part gallery or imported from a computer while creating or making changes to the Web Part Page in personal view. Private Web Parts are only available to the user who added or imported the Web Part. No other users can see private Web Parts.

The type of Web Part you are working with can be important because:

You may have permission to modify only some types of Web Parts on certain Web Part Pages, but not on other Web Part Pages.
You may be able to connect to certain types of Web Parts on a Web Part Page, but not to other types of Web Parts on the same Web Part Page.

There are significant benefits to the Web Part Architecture and to separating the instances of the Web Part description files (.dwp) from the Web Part assembly file (.dll).

Shareability Users can easily personalize Web Parts without affecting other users' instances of the same Web Part. Users and site administrators can easily share instances of Web Parts, either by sending the Web Part description file through e-mail or by transferring the Web Parts to other site galleries.

Transportability A primary advantage of the Web Part description file is that it is small and therefore easy to transport and duplicate. When you export, import, download, or upload a Web Part, the Web Part description file is the one you actually manipulate.

Performance Because the Web Part assembly file is precompiled code, it speeds up the execution of the Web Part Page. The Web Part Page does not have to interpret extensive code and logic. Because there is only one assembly file to install, site administrators have simple methods to "throttle" and control a Web Part or the number of Web Parts to ensure that no one user or Web Part Page can consume too many system resources.

Scalability Because Web Part properties are stored in database tables, many users can share Web Parts and create many instances of Web Parts without degrading overall system performance. Furthermore, you can balance workload or streamline Web Part installation by developing a Web Part Package file (.cab) and deploying Web Parts in a Virtual Server Web Part Gallery.

Security By using the standard rights and site groups in Microsoft Windows SharePoint Services, a site administrator can control who can access a Web Part Page, view or modify List View Web Part data, personalize the Web Part Page, add or delete Web Parts, or modify Web Part properties. A site administrator can also control which Web Parts are installed on a site and whether or not they can run on that site.

Maintenance Site administrators can easily control which Web Parts run on a site by controlling the installation of the Web Part assembly file. In addition, if a Web Part needs changes, or if a new version with added features becomes available, site administrators need to install only the new assembly file and any new resource files for all instances of the Web Part to see the new changes and features.

Web Parts are highly portable and are designed to be easy to export, transport, and import. When you personalize a Web Part or when a site administrator makes a change to a Web Part Page for all users, you or the site administrator may want to share it with other users at your site or even another site. For example:

You can export the Web Part from a Web Part Page, and then send the Web Part description file (.dwp) in e-mail to other users. Other users can then import the Web Part onto a Web Part Page. Alternatively, a site administrator could upload the Web Part directly into a Web Part gallery so all users can access it.
A site administrator can export a Web Part from a Web Part gallery and then save the file to a public location. Other users can then import the Web Part onto a Web Part Page. Or, another site administrator can upload the Web Part description file into another Site Web Part Gallery.

In all cases, it's important to ensure that the Web Part assembly file is also installed on the new site so that the new Web Part you created can run on the new site.

Note You cannot export a List View Web Part. Lists are specific to a site and cannot be transported to other sites in the same way as other Web Parts. If you want to move list data from one site to another, you can export the list data from one site, and then import the data into a list to the other site, which will then automatically add a List View Web Part of the new list data to the other Site Web Part Gallery.