Introduction
Web Parts is a framework built into ASP.NET 2.0 for building highly customizable portal-style pages. End users can customize Web Parts pages by changing the page layout, adding and removing Web Parts, editing Web Parts properties, establishing connections between Web Parts, and more. Changes made to a Web Parts page are persisted by the Web Parts framework.
The Web Parts framework is often compared to Microsoft SharePoint Portal Server because both can be used to produce rich portal-style applications. The chief difference between them is that Web Parts is an application framework, whereas SharePoint Portal Server is an application featuring tools and components for building portal sites.
Building Web Parts
There are two basic ways to create a Web Part. You can treat any standard Microsoft ASP.NET control as a Web Part or you can build a custom control that derives from the base WebPart class.
You are not required to modify a control in any way to use it as a Web Part. Standard ASP.NET controls (such as the Calendar and GridView controls), Web User Controls, and even custom controls can all be used as Web Parts. When you treat a standard control as a Web part, the control is represented in the Web Part framework with the GenericWebPart class.
Alternatively, you can build a custom Web Part control by building a new control that derives from the base WebPart class. The advantage of this second method of creating a Web Part is that it provides you with additional options for customizing the appearance and behavior of the Web Part. Custom Web parts allow adding verbs to their verbs menus. Sample WebPart application is shown below:
![001.JPG]()
Note: I have provided the source code for Web Parts application. Kindly download the source code and run the application to for web parts demonstration.
WebPart Controls
WebPartManager
WebPartManager is the most important of all the Web Part controls, responsible for managing and coordinating all controls inside WebPartZones. The Web Parts framework doesn't work without it, so every page that uses Web Parts must have an instance of WebPartManager declared, and it must be declared before other Web Parts controls. WebPartManager has no UI, so it's not visible on the page. It also exposes a very rich API for adding Web Parts to the page, closing Web Parts, connecting Web Parts, and more.
WebPartZone
WebPartZone is arguably the second most important Web Part control. It's used to define zones, which serve as containers for Web Parts. There is no practical limit to the number of WebPartZones a page can contain, and no limit to the number of Web Parts that a zone can contain. A WebPartZone control can host controls that do not derive from the WebPart class, by wrapping them with a GenericWebPart control at run time.
WebParts 'Welcome' and 'Calendar' are in WebPartZone 1 and WebPartZone 2 respectively in figure below:
![002.JPG]()
![003.JPG]()
User can drag and drop web parts from one WebPartZone to another WebPartZone in Design mode.
Catalog Zone
One of the chief benefits to building pages from Web Parts is that the content of these pages can be interactively configured by the user. It's a simple matter, for example, to enable users to restore closed Web Parts to the page by including a CatalogZone in the page.
The purpose of the CatalogZone control is to allow end users to customize Web Parts pages by adding Web Parts to them. Web Parts can come from three sources: Web Parts that were previously present in the page but were closed, Web Parts that don't appear on the page by default but that can be added, and Web Parts imported from .WebPart files.
A CatalogZone control becomes visible only when a user switches a Web page to catalog display mode (CatalogDisplayMode) as shown below:
![004.JPG]()
CatalogPart:
CatalogPart controls provide the UIs for adding Web Parts to the page. A CatalogZone can contain any combination of CatalogParts.
A CatalogZone can contain several types of CatalogPart controls. The following list summarizes the CatalogPart controls provided with the Web Parts control set:
- PageCatalogPart
- DeclarativeCatalogPart
- ImportCatalogPart
PageCatalogPart
The PageCatalogPart class serves one very specific purpose on a Web Parts page: it acts as a page catalog to contain any controls previously added to the page that a user has closed, and that the user can add back to the page. Add a PageCatalogPart control to your page if you want to provide users with the flexibility of closing and reopening controls. If your page does not allow users to close controls at all, there is no need to add a PageCatalogPart control to your page.
![005.JPG]()
DeclarativeCatalogPart
The DeclarativeCatalogPart control provides a way for developers to add a set of server controls declaratively to a catalog on a Web page. A catalog, in the Web Parts control set, is simply a list of WebPart or other server controls that is visible when a page is in catalog display mode. A user can select controls from the list and add them to the Web page, which effectively gives users the ability to change the set of controls and the functionality on a page, as shown below:
![006.JPG]()
ImportCatalogPart
The ImportCatalogPart control enables users to import a description file that describes settings on a WebPart control or server control that a user wants to add to a Web page. After the user has imported the description file, the WebPart control referenced in the file appears within the ImportCatalogPart control when the page is in catalog mode, and a user can then add the control to the page. User can view the ImportCatalogPart in Catalog Display mode, as shown below. User can browse the web part file and then upload by clicking Upload button.
![007.JPG]()
Editor Zone
The purpose of the EditorZone control is to allow end users to customize Web Parts pages by editing the properties of the page's Web Parts. Editing UIs are provided by EditorPart controls, which divide Web Part properties into four categories:
Properties that affect appearance, Properties that affect behavior, Properties that affect layout and Custom properties added by Web Part developers.
An EditorZone can contain any combination of EditorParts. EditorZones are only visible when the display mode is EditDisplayMode. User can click the Edit verb from webpart to open the Editor Zone.
![008.JPG]()
Editor Zone with AppearanceEditorPart
![009.JPG]()
Editor Zone with BehaviorEditorPart
![010.JPG]()
Editor Zone with LayoutEditorPart
Web Parts can and often do implement custom properties to complement the built-in properties provided by the Web Parts framework. A Web Part that shows stock prices, for example, might implement a public property named "Stocks" to enable end users to specify which stock prices are shown. PropertyGridEditorParts provide UIs for editing custom properties. Attributing a property [WebBrowsable] enables that property to appear in a PropertyGridEditorPart. Of course, the PropertyGridEditorPart must be declared in an EditorZone if it's to appear on the page.
WebPart Connection
Connections enable Web Parts to share data. A classic example is a Web Part control that shows the current weather and allows the user to enter a zip code so the weather can be localized. Another Web Part on that page--perhaps one that shows news headlines--might want that zip code so it, too, can localize content. Rather than require the user to enter the zip code twice, you can connect the two Web Parts so that one can get the zip code from the other. Connections can be defined statically by page developers, or they can be created dynamically by end users. The ConnectionsZone control provides a UI for creating connections dynamically.
Connection Provider
Writing a connection provider is no more difficult than writing a method that returns an interface reference and attributing that method [ConnectionProvider]. The first parameter to [ConnectionProvider] assigns a friendly name to the provider connection point and is displayed by the ConnectionsZone UI. The second parameter assigns a unique ID to the provider connection point. A provider can implement multiple provider connection points if desired. Each provider connection point must be assigned a unique ID.
ConnectionConsumer
Writing a connection consumer is a matter of writing a method that receives an interface reference and attributing that method [ConnectionConsumer]. The first parameter to [ConnectionConsumer] assigns a friendly name to the consumer connection point and is displayed by the ConnectionsZone UI. The second parameter assigns a unique ID to the consumer connection point.
![011.JPG]()
The mechanics underlying Web Part connections is simple. In each page request, the WebPartManager enumerates the connections that are defined. Then, for each connection, it calls the connection provider's [ConnectionProvider] method to retrieve an interface and passes the interface to the corresponding connection consumer by calling the consumer's [ConnectionConsumer] method. The connection consumer then makes calls through the supplied interface to fetch data from the connection provider, as shown in figure above.
Each <asp:Connection> element defines one connection. A connection is characterized by the Web Parts at either end of the connection (the provider and the consumer) and by the connection point IDs on each Web Part.
ConnectionZone
You can allow users to dynamically create connections between Web Parts. The ConnectionZone control provides a UI for making connections. Note there are no "ConnectionsPart" controls as there are EditorParts and CatalogParts; simply declaring a ConnectionZone and setting the display mode to ConnectDisplayMode is sufficient to display a connection UI.
Customizations applied to Web Parts pages by users--for example, changes to the page layout and changes to Web Part properties--are persisted using the Web Parts personalization service. The service is provider-based, and it can be accessed programmatically using the methods and properties of the System.Web.UI.WebControls.WebParts.PersonalizationAdministration class. The personalization service also persists custom properties that are attributed [Personalizable].
The fact that Web Parts personalization is provider-based adds a lot of flexibility to where Web Parts properties are persisted.
First add the 'Provider Web Part' to WebPartZone 1 and 'Consumer Web Part' to WebPartZone 2. Click the Connections link in browser window. Then click the Connect verb from Provider Web Part as shown in figure below.
![012.JPG]()
Clicking on Connect verb displays the Connections Zone, as shown in figure below.
![013.JPG]()
Click on 'Create a connection to a Consumer' in Connections Zone, select the web part to connect to (Consumer Web Part) and click Connect to create connection between Provider Web Part and Consumer Web Part.
![014.JPG]()
Once connection is established, user can type text in Provider Web Part and click Transmit button to transmit the text to Consumer Web Part.
![015.JPG]()
Export WebPart
You can export a Web Part to a .WebPart file by selecting the Export command from the Web Part's verbs menu. That command only appears in the verbs menu if the Web Part's ExportMode property is set to WebPartExportMode.All or WebPartExportMode.NonSensitiveData. A .WebPart file contains an XML representation of the Web Part's state at the time it was exported. Properties not attributed [Personalizable] aren't persisted to .WebPart files. In addition, if ExportMode=WebPartExportMode.NonSensitiveData, only "nonsensitive" properties attributed [Personalizable] are exported. You can use specify whether a property is sensitive in the [Personalizable] attribute. Examples of sensitive properties that perhaps should not be exported are passwords and social security numbers.
A Web Part exported to a .WebPart file can be imported using an ImportCatalogPart.
References