Udostępnij za pośrednictwem

Web Parts in SharePoint Foundation

  • Artykuł

Applies to: SharePoint Foundation 2010

Web Parts are server-side controls that run inside the context of site pages in Microsoft SharePoint Foundation. There are many Web Parts available by default, and you can also build your own custom Web Parts in SharePoint Foundation. They are editable and configurable by users. Web Parts let users add functionality to a site page by simply putting them on the page. SharePoint Foundation includes many default Web Parts. In addition, you can build your own Web Parts.

Types of Web Parts in SharePoint Foundation

There are two types of Web Parts in SharePoint Foundation. Both are supported, but Microsoft ASP.NET Web Parts are the recommended type for your projects.

  • ASP.NET Web Parts — These Web Parts are built on top of the ASP.NET Web Part infrastructure. The ASP.NET-style Web Parts have a dependency on System.Web.dll and must inherit from the WebPart base class in the System.Web.UI.WebControls.WebParts namespace. You can use these Web Parts in ASP.NET applications and in SharePoint Foundation, which makes them highly reusable.

    Note

    If you are creating your Web Part specifically for a SharePoint site, and it will consume the SharePoint Foundation object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.

  • SharePoint-based Web Parts — These Web Parts have a dependency on Microsoft.SharePoint.dll and must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. These Web Parts can only be used in SharePoint websites.

    Note

    For more information about when to derive from the SharePoint FoundationWebPart class, see Web Part Infrastructure in SharePoint Foundation.

SharePoint Web Part Infrastructure

The SharePoint Foundation Web Part infrastructure is built on top of a control named SPWebPartManager, which is derived from the ASP.NET WebPartManager control. The SPWebPartManager control overrides the standard behavior of the WebPartManager control to persist Web Part data inside the SharePoint Foundation content database instead of in the ASP.NET services database. In most cases, you do not have to worry about dealing directly with the SPWebPartManager control because the one required instance is already defined in v4.master. When you create a site page that links to v4.master, the SPWebPartManager control is already there. If you create your own custom ASPX pages that do not reference v4.master, and you want to support adding Web Parts to Web Part zones, you must add an SPWebPartManager control to the page.

Note

To create Web Part zones for a Web Parts page in SharePoint Foundation, you should use the WebPartZone control that is defined inside the Microsoft.SharePoint.WebPartPages namespace, instead of using the standard WebPartZone control from ASP.NET.

When you create a Web Parts page for a standard ASP.NET application, you must add logic that interacts with the WebPartManager control to manage the Web Part display mode. Generally, you must also explicitly add editor parts and catalog parts to the page together with the HTML layout to accommodate them. Fortunately, you do not have to perform these changes when you create site pages for a SharePoint Foundation site. Instead, you inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.WebPartPages namespace, and it does all the work behind the scenes for you.

For more information about creating ASP.NET Web Parts, see Developing Web Parts in Windows SharePoint Services and Web Parts Control Set Overview in the ASP.NET documentation.

Custom Web Parts

Custom Web Parts provide you with a method to create user interface elements that support both customization and personalization. The term customization implies that changes are seen by all site members. Individual users can further personalize Web Parts page by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes are seen only by the user who made them. A site owner or a site member who has the appropriate permissions can customize Web Parts page by using a browser or by using Microsoft SharePoint Designer to add, reconfigure, or remove a Web Part.

Because the SharePoint Foundation Web Part infrastructure is now built on top of the ASP.NET Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts. You can extend SharePoint sites by creating custom Web Parts, to add the extra dimensions of user customization and personalization. Developing custom Web Parts provides an easy and powerful way to extend SharePoint Foundation sites.

The following are some ways in which you can benefit from and use custom Web Parts:

  • Create custom properties that you can display and modify in the user interface.

  • Improve performance and scalability. A compiled custom Web Part runs faster than a script.

  • Implement proprietary code without disclosing the source code.

  • Secure and control access to content within the Web Part. Built-in Web Parts enable any users who have the appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.

  • Make your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.

  • Interact with object models that are exposed in SharePoint Foundation. For example, you can create a custom Web Part to save documents to a SharePoint Foundation document library.

  • Control the Web Part cache by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.

  • Benefit from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2010.

  • Create a base class for other Web Parts to extend. For example, to create a collection of Web Parts that have similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.

  • Control Web Part implementation. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.

Connectable Web Parts

The Web Part infrastructure provides a standardized set of interfaces called connection interfaces that allow Web Parts to exchange information with one another at run time. For example, the List Web Part that is built into SharePoint Foundation can provide (send) a row of data to any other Web Part that can consume (receive) that row, such as a Web Part that implements a form to display the row.

Because the Web Part infrastructure provides a standard set of connection interfaces, connectable Web Parts can be developed by entirely different developers or companies to communicate with one another. A Web Part that supports connection interfaces can be connected by an end user with either Microsoft SharePoint Designer or a Web browser. This enables end users to build sophisticated combinations of Web Parts through a simple menu-driven user interface.

For more information, see the following topics.

See Also

Tasks

How to: Export an ASP.NET Web Part and Import it to a SharePoint Foundation Site

Reference

Microsoft.SharePoint.WebPartPages

Microsoft.SharePoint.WebPartPages

Microsoft.SharePoint.WebPartPages.WebPart

WebPart

Concepts

Web Part Infrastructure in SharePoint Foundation

Other Resources

Developing Web Parts in Windows SharePoint Services

Best Practices: Common Coding Issues When Using the SharePoint Object Model