Go to page:
Prev 1 2 3 4 5 Next
2.4.3 IWebEditable
The last of the three interfaces that are implemented by all web parts is IWebEditable. This interface allows developers to associate custom editing controls with their web parts. We'll look at this interface in detail in chapter 5 and again, in even greater detail in chapter 8. For now we'll just look at an example to show why you would need to use this interface. Remember from chapter 1 that we created the simple portal example and that we added an AppearanceEditorPart to an EditorZone to allow some of the properties of the web part to be edited by users at runtime. Figure 2.10 shows us the editor zone with the AppearanceEditorPart displayed.
(continued)
Figure 2.10 The AppearanceEditorPart provides user interface elements that allow users to manage the appearance of web parts at runtime.
At runtime, users of our portal can access this AppearanceEditorPart to directly manipulate the appearance of web parts on the page.
Creating custom EditorParts
As you can see, the appearance editor provides us with user interface elements for managing the appearance of the web part—such as its Title, its Height, and Width. But what if you need special controls to manage a property of your web part? An example might be if we wanted to provide users of our weather web part with a map that allowed them to select their weather region visually. This is the kind of scenario that the IWebEditable interface is designed to manage, as it provides us with a way of assigning custom editor controls with our web part. To implement the IWebEditable interface, two members must be implemented:
- The CreateEditorParts method—which allows you to return a collection of all custom editor parts that you want to associate with your control
- The WebBrowsableObject property—which provides a way to return a reference to the underlying control that you wish to expose to your custom editor part.
To associate a custom map editor part with our weather web part, we start by adding code to the CreateEditorParts method which returns the custom editor control that we need to manage our zip code property. The following code shows what is required to return a custom editor part named ZipCodeSelector from the CreateEditorParts method:
public override EditorPartCollection CreateEditorParts() {
EditorPartCollection editorParts = base.CreateEditorParts();
editorParts.Add(new ZipCodeSelector());
return editorParts;
}
In the ZipCodeSelector editor part, we would include the rendering logic that we want to display when the part is displayed in the editor zone. As with all server controls, this is accomplished by writing some custom code in the Render method. In this case we'll add some code to display an icon and a link that the user can click to launch a larger map selection dialog. How do you do that? Figure 2.11 shows how the editor part would display in the browser when the code in listing 2.11 is executed.
Figure 2.11 The completed editor part is displayed in the editor zone whenever the associated web part is edited.
Figure 2.11 shows a custom editor section appearing in the EditorZone. The custom editor section has a title of "Untitled" and contains an icon—a picture of the globe—and a link that allows users to launch a completely custom dialog for selecting zip codes. The custom dialog that is launched could display an interactive map that allowed users to select postcodes in a more visual manner than the standard textbox control normally offered for entering postcodes.
Listing 2.11 The ZipCodeSelector editor part includes code for rendering its display when shown in the editor zone
(Full Size Image)
We could set this up so that when the user clicks on the "Display custom editor" link, a dialog is displayed that provides the user with a simple way to make region selections—such as a control that allows the user to view a map of the world and gives him a way to make selections by clicking on areas of the map.
Throughout this discussion on web part internals, we've seen that by implementing certain interfaces and behaviors, our web parts are able to work together with the other components of the portal framework cohesively. We've also seen that having different pieces of the framework communicating via interfaces provides for a high level of extensibility. This extensibility was demonstrated when we were able to easily pass our own custom editor parts for use in the EditorZone by simply implementing the IWebEditable interface.
Although the discussion in this chapter has focused thus far on extending the functionality of controls, there is one last topic that we should cover before moving on to more work on the Adventure Works Portal. That topic is themes. While themes are not a specific feature of web parts, our discussion on web parts would not be complete without mentioning them. Themes are common to all controls in ASP.NET 2.0, and offer a very flexible way to create websites that, in turn, offer flexible visual styles and layouts.
2.5 APPLYING THEMES AND STYLES
Prior to ASP.NET 2.0, we used Cascading Style Sheets (CSSs) to create sites with highly flexible styles and layouts. We used CSS to create styles and associate them with the HTML elements in your application. This approach works well when we know exactly the sort of HTML we are producing them for. The problem that arises when using ASP.NET 2.0 is that most of the time we are no longer working directly with raw HTML, but instead are working through the abstractions of server controls. For example, consider a standard server control tag for presenting the user with an EditorZone such as the one shown here:
<asp:EditorZone ID="EditorZone1" runat="server">
<ZoneTemplate>
<asp:PropertyGridEditorPart
id="PropertyGridEditorPart1"
runat="server" />
</ZoneTemplate>
</asp:EditorZone>
At runtime, this EditorZone server control is expanded into nearly a hundred lines of HTML markup, representing several hundred individual HTML elements. The difficulty for ASP.NET developers in the past lay in determining exactly what HTML was produced by server controls, and then mapping that to the relevant CSS styles.
Adding styles to controls
In ASP.NET 2.0, the themes feature provides a new way of creating styles for server controls. You can think of themes as style sheets for server controls. It's a good idea when developing any ASP.NET server controls—not just web parts—to extract all the style-related information contained in server controls and move it into a theme file. Having the style information separate from the presentation information provides us with the same level of flexibility that we had when using CSS alone in the past. For example, consider the Google site. It's a very simple site; but when you visit it on holidays or special occasions, it is customized for the occasion. If you go there on Easter, you are likely to see the Easter Bunny hovering just above the search textbox with his basket of Easter eggs at the ready. By grouping the style information regarding images, colors, and so forth into themes, you can easily achieve this kind of customization in your own applications. By creating several themes and applying different themes on different occasions, you could make your web parts look like pumpkins on Halloween!
Visual Studio 2005 supports the themes feature by offering new designer support for it. As shown in figure 2.12, nearly all server controls offer the developer support via the new Common Tasks feature. This feature reveals itself by offering a menu of additional features that can be accessed directly from a control when that control is viewed in design mode. In figure 2.12 we see the common tasks menu being displayed for the WebPartZone control with a single menu item that allows the user to Auto Format that control. Clicking on the menu item displays a dialog that allows the user to apply one of four named formats to that control. Figure 2.13 shows four zones, each with a different format applied to it. The name of the format is shown in the title of the web part.
(Full Size Image)
Figure 2.12 The common tasks dialog for the WebPartZone allows a developer to format that control.
When the web part zone is formatted, additional information is added to that control's declaration to describe to the ASP.NET runtime how the styles are to be applied. Listings 2.12 and 2.13 show the markup for a WebPartZone before and after it has style information added to it.
Figure 2.13 The four standard themes that come with ASP.NET 2.0.
Listing 2.12 A WebPartZone server control without any style-related attributes
<asp:WebPartZone ID="WebPartZone1" runat="server" />
Listing 2.13 A WebPartZone server control after applying a default theme
<asp:WebPartZone ID="WebPartZone1" runat="server"
BorderColor="#CCCCCC" Font-Names="Verdana" Padding="6">
<PartChromeStyle BackColor="#EFF3FB" BorderColor="#D1DDF1"
Font-Names="Verdana" ForeColor="#333333" />
<MenuLabelHoverStyle ForeColor="#D1DDF1" />
<EmptyZoneTextStyle Font-Size="0.8em" />
<MenuLabelStyle ForeColor="White" />
<MenuVerbHoverStyle BackColor="#EFF3FB" BorderColor="#CCCCCC"
BorderStyle="Solid"
BorderWidth="1px" ForeColor="#333333" />
<HeaderStyle Font-Size="0.7em" ForeColor="#CCCCCC"
HorizontalAlign="Center" />
<MenuVerbStyle BorderColor="#507CD1" BorderStyle="Solid"
BorderWidth="1px" ForeColor="White" />
<PartStyle Font-Size="0.8em" ForeColor="#333333" />
<TitleBarVerbStyle Font-Size="0.6em" Font-Underline="False"
ForeColor="White" />
<MenuPopupStyle BackColor="#507CD1" BorderColor="#CCCCCC"
BorderWidth="1px" Font-Names="Verdana"
Font-Size="0.6em" />
<PartTitleStyle BackColor="#507CD1" Font-Bold="True" Font-
Size="0.8em" ForeColor="White" />
</asp:WebPartZone>
As we can see, when the web part zone is formatted it becomes quite verbose because it contains so many style sub-elements. The biggest problem with having all that style information embedded in the page is that, if you decide to change the base look-and-feel for that control throughout your entire site, you have to go through all your pages and change every occurrence. If, however, you have used themes to style your controls, all style information for each of your server controls can be managed from a single place.
Creating themes
Now that we've seen the effect of having all of our style information embedded in pages, we are going to learn how to centralize this style information into a single location by using features known as Themes and Skin files. ASP.NET's feature, Themes, allows us to package style information such as style elements, images, and CSS files into folders. These folders contain
- Skin Files—Contain the style information for server controls—such as the style sub-elements shown in listing 1.13
- Images—Images that are associated with a specific theme—such as images of pumpkins for a theme named Halloween
- CSS Files—CSS information that compliments the colors and styles of the theme
These folders are then stored underneath a new, specially named folder called App_Themes within the application, and the names of the folders created underneath the App_Themes folder become the name of the theme. For example, we might want to create a theme for Valentine's Day, which has images of hearts and style information that is predominantly red. We could create a theme folder named "Valentine" to store the images and style information and images that are required to create the look-and-feel for that theme. This would include the style information for server controls, images that are associated with the theme, as well as any CSS files that we wish to use. Figure 2.14 shows the folder structure for a site that contains a blue Valentine.
Figure 2.14 This web application contains a theme named "Valentine."
To remove the style information from the web part zone and move it into a theme folder named Valentine, follow these steps:
- In your test web project, right-click on the solution folder and choose Add Folder, then select Theme Folder as the folder type.
- Add a folder underneath the theme folder and name it "Valentine."
- Right-click on the new Valentine theme folder and choose "Add Item" to add the file that will contain the style information for your server controls, and name the skin file "Valentine.skin".
The beauty of skin files is that they contain the definition of a server control in practically the same fashion as the definition would appear in a normal page, except that the theme definitions do not have an ID attribute. By the time all that style information for our web part zone is moved into the skin file, its control definition will be stripped back to its original state as shown in listing 2.12. After moving the style information into the skin file, it will as appear as it is displayed in listing 2.14:
Listing 2.14 Skin files store control definitions containing all of the style information for server controls.
<asp:WebPartZone runat="server" BorderColor="#CCCCCC"
Font-Names="Verdana" Padding="6">
<PartChromeStyle BackColor="#EFF3FB" BorderColor="#D1DDF1"
Font-Names="Verdana" ForeColor="#333333" />
<MenuLabelHoverStyle ForeColor="#D1DDF1" />
<EmptyZoneTextStyle Font-Size="0.8em" />
<MenuLabelStyle ForeColor="White" />
<MenuVerbHoverStyle BackColor="#EFF3FB" BorderColor="#CCCCCC"
BorderStyle="Solid"
BorderWidth="1px" ForeColor="#333333" />
<HeaderStyle Font-Size="0.7em" ForeColor="#CCCCCC"
HorizontalAlign="Center" />
<MenuVerbStyle BorderColor="#507CD1" BorderStyle="Solid"
BorderWidth="1px" ForeColor="White" />
<PartStyle Font-Size="0.8em" ForeColor="#333333" />
<TitleBarVerbStyle Font-Size="0.6em" Font-Underline="False"
ForeColor="White" />
<MenuPopupStyle BackColor="#507CD1" BorderColor="#CCCCCC"
BorderWidth="1px" Font-Names="Verdana"
Font-Size="0.6em" />
<PartTitleStyle BackColor="#507CD1" Font-Bold="True"
Font-Size="0.8em" ForeColor="White" />
</asp:WebPartZone>
As we can see, this skin file definition for the WebPartZone control looks almost identical to the WebPartZone control definition that we saw in listing 2.13. However, the difference is that this information is now stored in a single place—the skin file—and that all WebPartZone controls can now use this style without having to each have their own embedded style sub-elements. One more step is required to apply a theme within an application; you must configure the application so that it knows which theme to use. This configuration can be constructed either at page level or at application level in the web.config file. Both of these options are shown in listing 2.15.
Listing 2.15 Configuration entries for themes can be set at either page or configuration file level.
(Full Size Image)
The benefit of using the web configuration file to declare themes is that you are required to declare it in only one place, whereas declaring it in each page would result in many declarations. Having the theme declared in many different places makes the code more difficult to maintain, because a developer would have to locate each place that it was declared when making changes to the theme.
Now that you better understand web parts and have worked with them a bit, let's apply your new skills to the Adventure Works Cycles business.
Go to page:
Prev 1 2 3 4 5 Next
IE 7
Firefox 2.0
