Designing Your User Interface

The first step in creating a good web user interface is to create a design plan. In the design plan, you should

• Determine how users will navigate your site

• Decide which links will constitute top-level menu items

• Figure out how to create a unique, consistent look across the pages of the site

• Decide whether you will support multiple themes or user-configurable options

These and many more decisions go into the planning of a good, web-based UI.

When you have your plan, Visual Studio 2005 is there to help. It allows you to create master pages for determining a common look and feel. There are controls for managing links and menus. You can support themes through skin files. You can even allow users to participate in the customization of their layout using web parts. The following sections demonstrate the many features of ASP.NET that go into creating web UIs.

Determining Page Layout and Control Positioning

If you use the Visual Studio web page designer, then you will want to manage how controls are placed on a web page. For example, if you are used to building Windows forms, you may be more comfortable controlling the positioning of each individual item. In this case, you drag an item on the form and move it around relative to other items. This is called absolute positioning in web terms.

On the other hand, if you are more comfortable with the dynamic nature of a page in a browser, you may prefer to control your positioning through flow layout. This refers to your controls moving with the flow of the page. This capability is great if you intend to lay out your page with multiple tables and place your controls within table cells.

You can also mix both flow and absolute layouts. For example, you could define a page that flows based on tables. Inside a given cell, you might set a panel control. This panel control might be set to allow absolute positioning for items within the panel.

Setting Control Position Options

Visual Studio 2005 gives you a few options for managing how controls are added to pages by default. Within the Options dialog box, you can set these choices. You navigate to the HTML Designer/CSS Positioning node to do so. Selecting this node brings up the Options dialog box, as shown in Figure 13.23.

Figure 13.23. Selecting a form layout position.

You set your positioning options from the drop-down list. From here, you have four options that determine how controls are added to a page. Table 13.3 lists those options along with a description of each.

Table 13.3. Control Positioning Options

Option	Description
Absolutely Positioned	This option indicates that controls added to the web page have a defined position in terms of their left and top. They also have a layer or z-order. This option is useful if your controls overlap one another.
Relatively Positioned	This option is similar to Absolutely Positioned. The difference is that items are added to the page in a flow layout mode with top and left set to zero. You can then modify this information as and when necessary.
Statically Positioned	This option indicates that controls should be placed on the form using flow layout. That is, if a text box is placed as the first item on the form and then you add a button, the button is added to the right of the text box. In this way, the UI "flows."
No Positioning Attribute	With this option, controls are added to the form with flow layout. However, their layout can be changed or affected by a style.

Visual Studio also lets you control the positioning of individual items on a given form. To do so, you select the item and then choose the Position item from the Layout menu. See Figure 13.24 for an example. This foldout menu gives you easy access to the Options dialog box discussed in the preceding paragraphs. It also lets you override the positioning for individual controls.

Figure 13.24. Setting the positioning of individual items.

Creating a Common Look and Feel

When you create a website, you want the pages to look as if they all belong to one application. The navigation should be standard, the colors and fonts should match for like items, and sizing should be consistent. In addition, you don't want to have to manage this consistency across every single page in the site. This would be extremely tedious. In addition, if you decide to make a change, you would have to do so in every file.

Thankfully, you have the tools to support a consistent look across pages and make the management of it all much easier. Visual Studio provides styles, master pages, and themes to do so.

Style Sheets

Style sheets allow you to define a common look and behavior. You can then apply that common group to multiple items within your page and application. In this way, if you decide to change something, you can change it in one place and all the places that use the style will be updated.

As an example, suppose you want to manage how hyperlinks on your site look when a user hovers the mouse pointer over them. To do so, you can define a style inside a style sheet for the anchor tag's hover (A:hover) behavior. Inside the style, you might set the color, name, and size of the font. You might also toggle underlining. After you've defined your style, you then apply the style sheet to the page. All anchor tags on the page will then use the given style definition.

Creating a Style Sheet

You can add one or more style sheets to an application through the Add New Item dialog box. Style sheets have the extension .css. You can open a style sheet in the editor. When you do, Visual Studio presents a Style Sheet toolbar, CSS outline window, and the actual contents of style sheet. Figure 13.25 shows these items.

Figure 13.25. Working with a style sheet in the IDE.

The middle pane of Figure 13.25 shows the contents of the style sheet. You can manually edit the style sheet from here. Of course, being able to edit it requires you to have a good working understanding of CSS. Like anything, the more you work with it, the more familiar you will become. You can also use the context menu inside this pane to gain access to adding a new style rule and building a style with the style builder tool.

The Style Sheet toolbar has just a few options. The first one on the left launches the Add Style Rule dialog box. The second option opens the Style Builder window. The next button allows you to view the results in a browser window. Finally, the drop-down allows you to set a CSS standard with which to work.

The CSS Outline pane on the left of Figure 13.25 shows an outline view of the style sheet. If you don't intend to work with the raw .css file, this view and the related dialog boxes provide a nice set of tools. Items in this view are organized in two primary groups: Elements and Classes. The Elements group shows styles that define the look HTML elements. When a style sheet is applied to a page, the page's elements pick up these styles.

The Classes folder groups your custom styles. These styles are not related to elements. Rather, you define a custom style, give it a unique name in the sheet, and then explicitly apply it to individual items on your page.

Adding a Style Rule

A style rule defines a style for an element or class. You can create a new style rule by typing it directly into the editor (using the correct syntax, of course). For example, to create a new style class, you would type .myClass {} in the editor.

You can also define a style rule by using the Add Style Rule dialog box. You access this dialog box from either a right-click in the CSS outline pane, a right-click in the editor pane, a button on the Style Sheet toolbar, or the Add Style Rule option on the Style menu. This dialog box is useful in that it lists the many HTML elements for which you can define styles. It also allows you to define a style hierarchy. Figure 13.26 shows an example.

Figure 13.26. Adding a style rule.

Building a Style

You edit the contents of a given style either through the editor pane or the Style Builder dialog box. The latter provides a tool for setting the many options that can define a given style. This tool emits the correct markup for your style. You access the dialog box by right-clicking inside an existing style, selecting an option from the Style menu, or using a tool on the Style Sheet toolbar. Figure 13.27 shows an example of the dialog box. This figure represents the many options for controlling the font on a style. The Style Builder dialog box has many more options such as backgrounds, positioning, and borders.

Figure 13.27. Building your style markup.

Applying a Style Sheet to a Page

Your next step after creating a style sheet is to have it applied to your page. This is easy enough to do. You can drag and drop the style sheet from the Solution Explorer to any web page in the same Solution Explorer. You can also manually add the link tag to your page and point it to your style sheet. Next, we will look at master pages. It is worth noting that you can apply a style sheet to your master page. All pages that use the master will then have this style sheet applied.

Note

You can also define style for a single page. This is not a style sheet. In addition, you can use the inline style attribute to define styles on individual controls. This capability can be useful for overriding style sheetdefined styles.

Master Pages

Master pages are one of the greatest new additions to ASP.NET 2.0. They allow you to visually design a common look for your application in one file and then use that look across other files. This result was previously achieved through include files and user controls. However, these items were difficult to use in that they did not visually represent the final page in the designer. Instead, you had to run your browser to see the results of your combined HTML. In addition, you were often opening a table in one file that you had to remember to close in another. Master pages eliminate these issues. When you derive a page from a master file, Visual Studio displays the contents of both pages at once inside the designer.

Creating a Master Page

You add a master page to your project through the Add New Item dialog box. You can have multiple master pages in your application. This capability can be especially useful if your application has more than one default layout (or look) for certain areas of the site. It is most common to have a master page that includes common navigation, common graphics, and a common footer.

A master page defines the main HTML for the page. This includes the opening and closing HTML tags, head, body, and form. Inside the master page are one or more ContentPlaceHolder controls. These controls indicate areas on the page where content pages (pages that derive from the master) may place their content (such as a form definition).

Master pages also have their own code-behind file. This file should contain all code that relates to the workings of the master page itself. If there are working controls on the page, for example, their code would go inside this code-behind file. In addition, the master page has its own set of page events (just like an .aspx page).

Figure 13.28 shows an example of a master page. Notice that the page is laid out as a table. The cell in the center row contains a ContentPlaceHolder control. This is the only place where content pages that use the master page can add their content.

Figure 13.28. Creating a master page.

Creating a Content Page

Users do not access master pages directly. Instead, they call the content pages that derive from the master. When they do, .NET combines the contents of both pages and returns a single response as if there were only one page.

You create a content page by selecting a master when adding a web page to your site. When you do, there is an option titled Select Master Page at the bottom of the dialog box (recall Figure 13.12). Selecting this option will present you with available master pages in your application.

When your content page opens, you will see the content of the master page in the background. In the foreground will be the ContentPlaceHolder controls. It is here that you will add controls specific to your page. This provides a discrete separation of functionality between what is your page and what belongs to the master. You work with the page as you would any other ASP.NET web page. You add controls to the form and write event code in the code-behind file.

Note

Control layout and positioning can be important when you work with content areas. If, for example, you have turned on absolute positioning, then the content placeholder acts more as a guide. Due to the nature of this layout option, the content placeholder cannot restrict you from placing your controls anywhere on the page. The flow layout option, however, has the opposite effect. If you are working with static positioning, controls will be allowed only inside the content areas.

Figure 13.29 shows an example. This web page was created to edit a customer's profile; it is based on the application's master page. Notice that the content page has the same extension as any web form (.aspx).

Figure 13.29. Creating a content page.

Tip

You can use the Master object to reference the master page from the code within your content page's code-behind file. For example, suppose you want to set the instruction text on the master page from within each content page. Figure 13.29 shows an example. You would need to find the control used by the master page for the instruction text. This code would look like the following:

Label lb = (Label)this.Master.FindControl("LabelInstructions");

Themes and Skins

Visual Studio 2005 introduces the concept of themes for web pages and entire sites. This feature allows you to define one or more specific looks for the controls that make up your application. After you do, you can then switch between them based on user preference, their company affiliation, or similar.

At first glance, it seems themes provide nearly the same experience as style sheets. However, themes go a few steps further. First, they leverage style sheets. Each theme can have an associated style sheet. Themes can also be applied in such a way as to work with an existing style sheet or to override it (see "Applying a Theme to a Site or Page"). The next difference is that themes allow you to embed graphic files as part of the themes. In this way, you can switch between one set of graphics to another based on a theme's name. Style sheets cannot do this. Last, themes allow you to define skin files for your ASP.NET controls. These skin files enable you to set property values of a control that fall outside mere styles (these property values must be nonbehavioral, however).

Note

Only one theme can apply to a site at any given time (unlike style sheets).

Creating a Theme

Themes are created inside the App_Themes folder. Each theme gets its own theme folder. The name of the theme is the name of the folder (which must be unique). This ensures there is no confusion when applying a theme. You apply it based on the folder's name.

As an example, suppose you are building an application to manage customer details and orders. Assume this application is accessed from multiple company sites. Therefore, company A would manage its customers, and company B would manage its customers. In this scenario, the site owner might define a different theme for each company. Perhaps the theme is based on each company's colors, fonts, and graphics.

To create a theme, you typically follow a standard set of steps:

1.	You must first create the App_Theme directory. You can do so through the context menu. You choose Add ASP.NET Folder and then Theme. You can also choose to add a skin file to your application, and then Visual Studio will create the App_Theme directory for you.
2.	When you have the App_Theme directory, you can right-click on it to add a new theme folder. This can again be found under the Add ASP.NET Folder menu. You will want to name this folder with the name of your theme.
3.	Next, you add the files that make up your theme. These files typically include a style sheet, any images or resources, and a skin file.

Figure 13.30 shows the folder and file structure based on the example we discussed here.

Figure 13.30. Application themes.

Creating a Skin File

We have already discussed style sheets. What we need to look at now is defining a skin file. You can have one or more skin files in your theme. You might want to create a new skin file for each control you intend to skin. Alternatively, you may want to define a single skin file for your entire theme. The choice is yours.

Inside the skin file are control skin definitions called skins. You declare each skin just as you would write the markup for a given control on a web page. The syntax is similar. However, you omit the property assignments for the control that do not pertain to the skin.

There are two types of skin definitions: named skins and unnamed skins. A named skin is created by using the attribute SkinId. This allows you to define a unique name for the skin declaration. In this case, only controls in your site with this same SkinId will be affected by the skin declaration. On the other hand, unnamed skins apply to all controls of a similar type. For example, if you want all your button controls to look a similar way, you create an unnamed skin for the button control. When you apply the skin to a page, then all buttons will pick up this look. Let's look at an example.

For this example, say you want to define a few skins to define your theme. You will define named skins for the customer logo on the master page and the title labels on each screen. You will then create unnamed skins for label, text box, button, and grid view controls.

Listing 13.1 shows the sample skin file. At the top are the named skins. Notice the use of the SkinId attribute. Again, this attribute will be used when applying this skin to specific instances of these types of controls (image and label in this case). Below this are the skins that apply to standard controls. There is one for all buttons, labels, text boxes, and grid views. Notice that the GridView definition includes definitions for the many parts of the control. You nest these definitions within the GridView definition as you would on any ASP.NET page.

You also need a similar file for company B. To create it, you copy and paste this file to that company's directory. You then make minor edits to the image skin and the fonts and colors of the other skin definitions. We will next look at applying these skins to the pages in the site.

Listing 13.1. Company A Skin File

<%-- named skins --%> <asp:Image runat="server" Skin  Height="60px" Width="128px"  ImageUrl="~/App_Themes/CompanyA/compaAlogo.jpg"/> <asp:Label runat="server" Skin  Font-Names="Arial Black"  Font-Size="X-Large" /> <%-- default, control skins --%> <asp:Button runat="server" Width="100px" Height="25px"  BackColor="Silver" ForeColor="MidnightBlue"  Font-Name="Arial" Font-Size="10px"  BorderColor="MidnightBlue" BorderStyle="Ridge" /> <asp:Label runat="server" ForeColor="MidnightBlue"  Font-Names="Arial" Font-Size="Small" /> <asp:TextBox runat="server" Width="265px" BackColor="White"  BorderColor="MidnightBlue" BorderStyle="Solid" BorderWidth="1px"  Font-Names="Arial" Font-Size="Small" /> <asp:GridView runat="server" CellPadding="4" ForeColor="#333333" GridLines="None">   <FooterStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" />   <RowStyle BackColor="#F7F6F3" ForeColor="#333333" />   <EditRowStyle BackColor="#999999" />   <SelectedRowStyle BackColor="#E2DED6" Font-Bold="True" ForeColor="#333333" />   <PagerStyle BackColor="#284775" ForeColor="White" HorizontalAlign="Center" />   <HeaderStyle BackColor="#5D7B9D" Font-Bold="True" ForeColor="White" />   <AlternatingRowStyle BackColor="White" ForeColor="#284775" /> </asp:GridView>

Tip

There is not much tool support for defining skin declarations. You are forced to manually enter this markup. However, a common shortcut can be to create a page that includes each control in the theme. You then use the designer to edit the controls on the page. Finally, you copy this markup from the page to the skin declaration and then delete any unwanted declaration code (including the ID tag).

Applying a Theme to a Site or Page

There are a few ways in which you can apply a theme. Each is meant to provide a different level of control. For example, you can set a global theme for an entire server. You can configure a theme for just one website. You can also choose to configure a theme at the individual page level. Finally, you can apply a single skin to a single control. You can see that these levels go from the very macro (server) to the granular (control). Most websites will fall somewhere in the middle, like applying a theme at the page or site level.

You apply a theme at the page level by using the @ Page directive inside the page's markup. You have a couple of options here. You can decide that your theme should always trump all control settings. That is, if a developer explicitly sets a control value and that value is overridden by the theme, then the theme takes precedence. This type of declaration would look like the following:

<%@ Page Theme="MyPageTheme" %>

Alternatively, you can set what is called a StyleSheetTheme at the page level. This indicates that the theme applies only where controls do not have explicit overriding values. In the previous declaration, the theme would override local control settings. Using the StyleSheetTheme, you can set the theme to apply only to control settings that are not explicitly set. That is, if the control has a value for a given attribute, then that value is used. If it does not, then the theme's value is used. You set this type of theme for the page as follows:

<%@ Page StyleSheetTheme="MyPageTheme" %>

You can define the theme for an entire website through the configuration file. This allows you to set a theme and then change it without recompiling your code. To do so, you add the Theme or StyleSheetTheme (see the preceding example) attributes to the pages element inside the system.web node. The following is an example:

<system.web>   <pages theme="MySiteTheme" /> </system.web>

To define just the style sheet theme, you would use the following:

<system.web>   <pages StyleSheetTheme="MySiteTheme" /> </system.web>

You can also set a theme inside your code. This capability can be useful if you are allowing users to choose their theme or you are dynamically setting a theme based on some user information. Recall the example with two companies: company A and company B. Remember, a theme file was defined for each. If you determine within your code that a member of company A, for example, has logged in, then you would set the theme as follows:

Page.Theme = "CompanyA"

Figure 13.31 shows an example of the theme defined in Listing 13.1. This theme was set programmatically.

Figure 13.31. Company A theme applied.

Figure 13.32 shows the same theme for company B. Here, the theme has been modified and applied programmatically to the entire site.

Figure 13.32. Company B theme applied.

Tip

You can make changes to a theme file or skin without recompiling your site. These changes will simply be applied on the next browser refresh.

To set a theme for a single control, you use the SkinID attribute of the control. This ID can be set to reference a particular skin inside a skin file. The skin definition would have the same skin ID as the one used inside the markup. The markup for this looks as follows:

<asp:SomeControl runat="server"  Skin />

You can set the skin ID from the markup or by using the Properties window for a given control open in the designer. This window will provide a drop-down list of skins that are available for the given control type. You can also set the skin ID programmatically. The following is an example:

SomeControl.SkinId = "MySkinId"

Creating a User-Configurable UI

ASP.NET 2.0 provides support for creating a user interface that can be configured and personalized by each individual user of a site. As an example, if you have ever worked with SharePoint Portal Server or visited MSN.com, you will notice that blocks of functionality define a given page. These blocks can be removed, added, moved around, and configured by users. To enable this functionality, the blocks all must work together as part of a portal framework. .NET now has just such a framework built into the product.

The following sections provide an overview of creating a configurable user interface using the new Web Part controls. We will walk through the basics of building a Web Part page that allows users to monitor customers in a customer management application. In doing so, we will cover the many basics of Web Parts. Note that this is another large topic. When you become familiar with the basics, you will want to do additional exploring to find out more.

Working with the Web Part Controls

There are many Web Part controls and classes; the Visual Studio Toolbox alone defines 13 Web Part controls (see Figure 13.33). In addition, the System.Web.UI.WebControls.WebParts namespace contains nearly 100 classes. These controls and objects work together to manage the structure of a Web Part page, its personalization and configuration, and the presentation itself.

Figure 13.33. The Web Part controls.

When you create a basic Web Part page, you typically work with three types of controls: the WebPartManager, WebPartZone, and presentation controls themselves. The first control, WebPartManager, is actually required of all Web Part pages. It is the control responsible for managing the Web Parts on the page. You must define this control on each Web Part page and can define only one per page. The WebPartManager is responsible for tracking the controls and their zones throughout the page. It also manages the state that a page might be in, such as view or edit mode.

The second control, WebPartZone, enables you to manage the layout or "zones" of your page. A zone represents an area of the page where controls or features can be placed. To understand zones, you can think of your page in terms of horizontal and vertical content zones. For example, you may have a zone at the top of your page that presents the header for the application. Beneath this, you may have two vertical zones. The leftmost zone may be used for links and navigational controls. The middle zone may contain content Web Parts. Finally, you may have another zone at the bottom of the page to manage footer-type content.

Figure 13.34 shows an example of a Web Part page broken into zones. Of course, you can define any number of zones and lay them out as you like. This is simply one example.

Figure 13.34. Web Part zones.

Note

Zones also have an associated style. That is, they define a header, title, border, buttons, and so on. This is known as the "chrome" of the controls.

Last, you put controls into each zone of the Web Part page. These controls can be any .NET control that you want to be managed by the zone. You can also create your own Web Parts and user controls that can be placed in these zones. The advantage of the latter is that you can provide configuration capabilities for these Web Parts. This allows users to edit a given Web Part's properties from within the web browser (similar to SharePoint).

Table 13.4 provides a brief reference to the primary controls that you use to manage a Web Part page. Each of these controls can be found on the Visual Studio Toolbox. These controls are all zone controls (except the manager control). As such, they constrain what type of control should be added to the given zone.

Table 13.4. The Web Part Zone Controls

Control	Description
WebPartManager	This control tracks the zones on the page and the WebPart controls that are in those zones. Each Web Part page requires one (and only one) instance of this control.
CatalogZone	This control defines a zone that contains one or more CatalogPart controls. The CatalogPart control provides a list of Web Parts that are available for the page. When a user is editing the page, this zone is enabled. Users then use the CatalogPart control to select one or more Web Part objects and drag them into WebPartZones.
WebPartZone	You use this control for defining the primary zones of your user interface. You can add ASP.NET controls and Web Part controls into these zones. Most Web Part pages define two or more WebPartZones.
EditorZone	You use this zone for providing an area for users to edit and configure a given Web Part. The editor for a Web Part is defined as an EditorPart control. This zone contains these types of controls.

Creating a Web Part Page

You create a Web Part page using any standard web form (.aspx). For the following example, you will create a form titled MonitorCustomer.aspx. The first step is to drag a WebPartManager control onto this form. This control has no visual appearance on the form. Instead, it is simply necessary to create a Web Part page.

Tip

Inside the form designer, you can decide to show or hide controls that have no visual appearance. To do so, you use the View menu and check or uncheck the option Non-Visual Controls. Non-visual controls show up as gray boxes inside the designer. A box typically contains a control's name and ID.

Defining Zones

Next, you add the zones to the page. Recall that the zones define where your Web Parts can exist and how they look and are sized. You can lay out your zones inside a table, use absolute positioning to place zones in specific areas, or use relative positioning. If you allow users to hide or close the controls in a zone, you might consider a table or relative positioning. If, on the other hand, your zones are static, you would use absolute positioning. In the example, you will do the latter. You can follow these steps to create the example:

1.	Place two WebPartZone controls on a web page.
2.	Name the first control Customer Links; it will take up the left side of the page.
3.	Set the first control's ID property to WebPartZoneCustomerLinks.
4.	Set the HeaderText property of the first control to Customer Links. This allows people editing the page to see a zone name (and, you hope, your intentions for the zone).
5.	Next, you define the chrome for the Web Parts that are placed in this zone. You can configure this through numerous properties of the zone or use the smart tag associated with the control to autoformat the zone. Figure 13.35 shows an example of the Auto Format dialog box. On the left are possible formats. On the right is a preview showing how the Web Parts in the zone will look. This preview is based on actual content for the zone.

Figure 13.35. Setting the chrome for a zone.

Repeat these steps for the other zone control. Place this one in the middle of the page and set its HeaderText property to Customer Statistics. This zone will be used to display statistics relative to customers shopping in the site.

Adding Web Parts to Zones

Now you're ready to add Web Parts to the zones you have defined. There are few ways to go about this. You can create actual controls that implement the WebPart class. This allows the most flexibility for creating Web Parts. It also allows you to create user configuration for your Web Parts. This configuration is shown when a user edits a given Web Part. This also happens to be the most involved method. Of course, it is recommended for portal developers. Alternatively, you can add ASP.NET controls or user controls to the zones. When you do so, ASP will define a Web Part around the given control. This makes for an easy way to create Web Parts.

For the example, you will implement the latter method. You will first create a Customer Links Web Part. This Web Part will provide a series of links around managing a customer. The following outlines the process for creating this Web Part:

1. Drag an ASP Label control inside the WebPartZone control.

2. This label will be automatically turned into a WebPart control. You can see this in the markup. The <ZoneTemplate> element is added inside the <asp:WebPartZone> node. Inside this goes the Label control you added to the form.

3. Set a title for the Web Part. To do so, add the title attribute to the Label control. This attribute is picked up by ASP and applied to the Web Part.

4. Add some links within the confines of the <asp:Label> declaration. The final markup looks something like Listing 13.2.

Listing 13.2. The Customer Links Web Part

<asp:WebPartZone  runat="server">   <ZoneTemplate>     <asp:Label title="Customer Links" runat="server" >       <a href="FindCustomer.aspx">Find Customer</a><br />       <a href="FindOrder.aspx">Find Order</a><br />       <a href="FindCustomer.aspx">Offer Discount</a><br />     </asp:Label>   </ZoneTemplate> </asp:WebPartZone>

Repeat this method for a Help Web Part. Then create some user controls. Create one for showing active shoppers, one for searching for an order, and one that shows the top products sold in a given day. You add the user controls to a zone in a similar way you added the ASP.NET controls. ASP turns each into its own Web Part and applies the zone's chrome to each control. Figure 13.36 shows what the page now looks like inside the designer.

Figure 13.36. The Web Parts inside the designer.

Enabling Users to Configure the Page

There are many options available for allowing users to customize the look and behavior of Web Parts. You can create editors for your controls that allow for full configuration. You might have Web Parts that can connect (or talk to) other Web Parts. They require configuration. You might allow users to pick from a catalog of controls in order to determine which controls they would like to see on the page. It is also common to allow users to minimize, close, and move your controls from zone to zone. The first two features come by default with Web Parts. We will look at enabling this last feature.

There are a few steps you need to take to enable users to change the layout of the page. These steps are as follows:

1.	Add an EditorZone control onto the page. Adding this control creates a zone where you can put EditorParts. It is typical for you to show this zone when your page is in edit mode. In the example, assume you are using the zone but do not intend to display to users.
2.	Add the LayoutEditorPart control to the EditorZone you just created. This Web Part allows for the page's layout to be edit-enabled.
3.	Create a user control for managing the edit mode. This user control will contain a single LinkButton control. This control should look like every other Web Part when added to the page.
4.	Write some code for the user control. First, add an event to pick up the WebPartManager instance that is managing the control. Next, respond to the button's Click event and then toggle the state of the WebPartManager between either edit or browse mode. Listing 13.3 shows this code.
5.	Add the control to a zone on the Web Part page. Figure 13.37 shows both this control and the editor Web Parts in the designer.

Figure 13.37. The edit mode and Editor Zone Web Parts in the designer.

Listing 13.3. Controlling Edit Mode for the Page

public partial class EditMode : System.Web.UI.UserControl {   WebPartManager _wpManager;   void Page_Init(object sender, EventArgs e) {     Page.InitComplete += new EventHandler(InitComplete);   }   void InitComplete(object sender, System.EventArgs e) {     wpManager = WebPartManager.GetCurrentWebPartManager(Page);   }   protected void LinkButton1_Click(object sender, EventArgs e) {     if (LinkButton1.Text == "Edit Mode: OFF") {         wpManager.DisplayMode = _wpManager.SupportedDisplayModes["Edit"];         LinkButton1.Text = "Edit Mode: ON";     }     else {       wpManager.DisplayMode = _wpManager.SupportedDisplayModes["Browse"];       LinkButton1.Text = "Edit Mode: OFF";     }   } }

Viewing the Results

The final step is to view and debug the results. Figure 13.38 shows the Monitor Customers page in a standard browse view. Notice that the Customer Links Web Part has been minimized. In addition, the menu off the Web Part toolbar has been highlighted. In browse mode, this menu contains links for closing the Web Part and minimizing it. Of course, these actions are configurable.

Figure 13.38. Choosing to minimize or close a Web Part.

If you click the Edit Mode link button, you can toggle the page into edit mode. When in edit mode, users see the available zones and their titles. They are now allowed to move Web Parts from zone to zone. Figure 13.39 show this movement in action.

Figure 13.39. Moving Web Parts between zones.

When the page is in edit mode, users get the edit action inside the toolbar's menu by default. This action enables editing for the given Web Part. In this example, this means displaying the Editor Zone, which contains the LayoutEditorPart control. Figure 13.40 shows an example of this zone enabled.

Figure 13.40. Invoking the layout editor for a Web Part.

Tip

Web part personalization is persisted from session to session. If users (or developers) close controls, you need to give them a way to get them back. For this example, a link was added in the edit mode control to do just this. Inside the Click event is the following, which is used to reset the personalization for the page:

_wpManager.Personalization.ResetPersonalizationState().