Home > SKIP > Visual Studio .Net > Web Parts

Web Parts

Web Parts & Their Implementation

ASP.NET Web Parts controls are an integrated set of controls for creating Web sites that enable end users to modify the content, appearance, and behavior of Web pages directly in a browser. The topics in this section provide information on what Web Parts are, how they work, and how to use them to create user-customizable ASP.NET Web pages.

Using the Web Parts control set, you as a developer can enable end users to:

  • Personalize page content. Users can add new Web Parts controls to a page, remove them, hide them, or minimize them like ordinary windows.
  • Personalize page layout. Users can drag a Web Parts control to a different zone on a page, or change its appearance, properties, and behavior.
  • Export and import controls. Users can import or export Web Parts control settings for use in other pages or sites, retaining the properties, appearance, and even the data in the controls. This reduces data entry and configuration demands on end users.
  • Create connections. Users can establish connections between controls so that, for example, a chart control could display a graph for the data in a stock ticker control. Users could personalize not only the connection itself, but the appearance and details of how the chart control displays the data.
  • Manage & personalize site-level settings. Authorized users can configure site-level settings, determine who can access a site or page, set role-based access to controls, and so on. For example, a user in an administrative role could set a Web Parts control to be shared by all users, and prevent users who are not administrators from personalizing the shared control.

Consists three main building blocks

  • Personalization
  • User interface (UI) structural components
  • Actual Web Parts UI controls
  • Personalization is the foundation of the Web Parts feature. It enables users to modify--or personalize--the layout, appearance, and behavior of Web Parts controls on a page. The personalized settings are long-lived: they are persisted not just during the current browser session (as with view state), but also in long-term storage, so that a user's settings are saved for future browser sessions as well.
  • The UI structural components rely on personalization and provide the core structure and services needed by all Web Parts controls. One UI structural component required on every Web Parts page is the WebPartManager control.

Examples of UI Structural Component

  1. WebPartManager has the critical task of coordinating all Web Parts controls on a page.
    • It tracks all the individual web part controls
    • It manages Web Parts zones (regions that contain Web Parts controls on a page) and which controls are in which zones.
    • It also tracks and controls the different display modes a page can be in, such as browse, connect, edit, or catalog mode, and whether personalization changes apply to all users or to individual users.
    • It also initiates and tracks connections and communication between Web Parts controls.
  2. Zones:
    • Zones act as layout managers on a Web Parts page
    • It provides the ability to do modular page layout in either horizontal or vertical orientation.
    • It offer common and consistent UI elements (such as header and footer style, title, border style, action buttons, and so on) for each control they contain. (these common elements are known as the chrome of a control).

Web Parts UI Controls

The Web Parts UI controls, all of which derive from the Part class, comprise the primary UI on a Web Parts page. (Example: Existing ASP.NET server controls, user controls, or custom server controls as Web Parts controls)

  • Part: The Part class defines properties that are common to all part controls and enable them to have a modular and consistent appearance on a Web page like title, a description, and characteristics of the chrome or frame that surrounds a part control. (Types: WebPart, CatalogPart, EditorPart)
  • While part controls usually reside in zones, it is possible to place a part control outside a zone, if the control is referenced declaratively in the markup of a Web page. If a part control is declared outside a zone on a Web page, the control still works, but loses most of its Web Parts functionality. For example, the control cannot be edited, and cannot be dragged into a zone at run time. It is also helpful to remember that no part control can be dragged from a zone and dropped onto a page outside of a zone at run time.

Web Parts Page Structure

Web Parts Page Structure

Web Parts Control Description
Web Part Manager Manages all Web Parts controls on a page. One (and only one) Web Part Manager control is required for every Web Parts page.
Catalog Zone Contains Catalog Part controls. Use this zone to create a catalog of Web Parts controls from which users can select controls to add to a page/WebPartZone.
Editor Zone Contains Editor Part controls. Use this zone to enable users to edit and personalize Web Parts controls on a page.
Web Part Zone Contains and provides overall layout for the Web Part controls that compose the main UI of a page. Use this zone whenever you create pages with Web Parts controls. Pages can contain one or more zones.
Connection Zone TheConnectionsZone Web server control provides a user interface (UI) that enables users to form connections between WebPart and other server controls that reside in WebPartZoneBase zones.

Web Parts Page Summary:

  1. Page will be divided into zones to manage the layout.
  2. Each zone will be treated as a column and each zone will have set of web part controls.
  3. Each page can have only one web part manager.

Developer Scenarios:

You will typically work with Web Parts in one of three ways: creating pages that use Web Parts controls, creating individual Web Parts controls, or creating complete, personalizable Web applications, such as a portal.

  • Page Development
  • Control Development
  • Web Application Development

A configured personalization provider and database. Web Parts personalization is enabled by default, and it uses the SQL personalization provider (SqlPersonalizationProvider) with the Microsoft SQL Server Standard Edition to store personalization data.

ASP.NET Web Parts Life Cycle

ASP.NET Web Parts Life Cycle

  • Initialization
    The WebPartZone objects register with the WebPartManager control.
    The WebPartManager control loads the static WebPart objects.
    The WebPartManager control calls the TrackViewState method for each static
    WebPart object already in the control hierarchy at this point.
  • Initialization Complete
    The WebPartManager control loads the dynamic WebPart objects and the WebPartConnection objects. The WebPartManager control calls the WebPartPersonalization control on the static and dynamic WebPart objects.
  • Load Complete
    The WebPartManager control activates the WebPartConnection objects.
  • Save State Complete
    The WebPartManager control saves the static and dynamic WebPart objects' personalization information in permanent storage.

Declare a Static Connection between Two Web Parts Controls

Developers can create a static Web Parts connection between two server controls by declaring the connection in page persistence format. A static connection becomes a permanent object on a Web page, like a declared control. All users can see a static connection.

Syntax:

<StaticConnections>
<asp:WebPartConnection ID="conn1" ConsumerConnectionPointID="ZipCodeConsumer" ConsumerID="weather1" ProviderConnectionPointID="ZipCodeProvider" ProviderID="zip1"/>
</StaticConnections>

The above should be declared inside the web part manager.

Properties:

  • ConsumerID - Indicates the ID of the consumer control in the connection.
  • ConsumerConnectionPointID - Indicates the ID of a special callback method in the consumer used to establish the connection. This attribute is required only if the consumer has more than one connection point.
  • ProviderID - Indicates the ID of the provider control in the connection.
  • ProviderConnectionPointID - Indicates the ID of a special callback method in the provider used to establish the connection. This attribute is required only if the provider has more than one connection point.

Editor Zone:

Several controls in the Web Parts control set provide the editing features. This includes the EditorZone control, which is the primary control in the Web Parts control set for hosting EditorPart controls on a Web page.

Web Parts Control Description
AppearanceEditorPart Lets users customize the visual properties of a WebPart control at run time, such as the width, height, and title.
BehaviorEditorPart Lets users customize behavior properties of a WebPart control at run time, such as displaying minimize, close, and edit buttons.
LayoutEditorPart Lets users customize layout properties of a WebPart control at run time, such as selecting a minimized or normal state, or setting the index at which the control will appear within the target zone.
PropertyGridEditorPart Lets users edit custom properties at run time that are declared as part of a WebPart control.

CatalogZone:

  • Contains 3 features to import a control at run time.
  • DeclarativeCatalogPart Web Server Control Overview
  • PageCatalogPart Web Server Control Overview
  • ImportCatalogPart Web Server Control Overview
  • The PageCatalogPart control acts as a page catalog to maintain any controls that were previously added to the page and that a user has closed. Later, the user can add them back to the page. This control is visible only when a Web page is in catalog-display mode.

Web Parts Personalization:

  • Long-lived. Personalized settings are not tied to a single browser session. Because they are stored in long-term storage, the application can retrieve a user's settings each time the user visits a specific page.
  • Personalization is different from view state. View state and personalization both persist control state data, but view state data only persists during the current browser session, while personalization data is long-lived.
    3 Key Concepts in Personalization.
  • Page Personalization scope. Page personalization scope is the range of users to which personalization changes on a page can apply. At any given time, a Web Parts page can be in one of two possible page personalization scopes, Shared or User.
  • Control Visibility: whether control is added dynamically or static
  • Property Scope: can set personalizable=”shared”/”user”
    ASP.NET 2.0 ships with a provider for SQL Server called the “SqlPersonalizationProvider” class, which resides in the “System.Web.UI.WebControls.WebParts” name space. This class contains a SQL Server-specific implementation of the abstract methods from the “PersonalizationProvider” class. This means that the class contains a lot of code to connect to a SQL Server database, to query the database for pertinent records, and to read the data returned by SQL Server.

Can disable it in page with syntax:
<asp:webpartmanager runat="server" id="wpmgr1" personalization-enabled="false" />

References