Evjen c17.tex V2 - 01/28/2008 2:58pm Page 857
Chapter 17: Portal Frameworks and Web Parts
<
form id="form1" runat="server"
>
<
div
>
<
asp:WebPartManager ID="WebPartManager1" runat="server"
>
<
StaticConnections
>
<
asp:WebPartConnection ID="WebPartConnection1"
ConsumerID="ModifyableCalendar1"
ConsumerConnectionPointID="CalendarTitleConsumer"
ProviderID="TextBoxChanger1"
ProviderConnectionPointID="TextBoxStringProvider"
>
<
/asp:WebPartConnection
>
<
/StaticConnections
>
<
/asp:WebPartManager
>
<

table cellpadding="3"
>
<
tr valign="top"
>
<
td style="width: 100px"
>
<
asp:WebPartZone ID="WebPartZone1" runat="server"
>
<
ZoneTemplate
>
<
connectionControls:TextBoxChanger
ID="TextBoxChanger1"
runat="server" Title="Provider Web Part" /
>
<
/ZoneTemplate
>
<
/asp:WebPartZone
>
<
/td
>
<
td style="width: 100px"

>
<
asp:WebPartZone ID="WebPartZone2" runat="server"
>
<
ZoneTemplate
>
<
connectionControls:ModifyableCalendar
ID="ModifyableCalendar1" runat="server"
Title="Consumer Web Part" /
>
<
/ZoneTemplate
>
<
/asp:WebPartZone
>
<
/td
>
<
/tr
>
<
/table
>
<
/div
>

<
/form
>
<
/body
>
<
/html
>
This ASP.NET page that utilizes Web Parts contains a single two-cell table. Each cell in the table contains
a single WebPartZone control —
WebPartZone1
and
WebPartZone2
.
Before connecting the Web Parts, the new custom Web Part controls are registered in the ASP.NET page
using the
@Register
page directive. This directive simply points to the namespace
Wrox.Connection-
Management
. This is the namespace used by the interface and the two custom Web Part controls.
Each of the custom Web Parts is placed within its own WebPartZone control. The two Web Part controls
are tied together using the WebPartManager control.
<
asp:WebPartManager ID="WebPartManager1" runat="server"
>
<
StaticConnections
>

<
asp:WebPartConnection ID="WebPartConnection1"
ConsumerID="ModifyableCalendar1"
857
Evjen c17.tex V2 - 01/28/2008 2:58pm Page 858
Chapter 17: Portal Frameworks and Web Parts
ConsumerConnectionPointID="CalendarTitleConsumer"
ProviderID="TextBoxChanger1"
ProviderConnectionPointID="TextBoxStringProvider"
>
<
/asp:WebPartConnection
>
<
/StaticConnections
>
<
/asp:WebPartManager
>
The WebPartManager server control nests the defined connection inside of the <
StaticConnections
>
section of the declaration. The definition is actually accomplished using the WebPartConnection server
control. This control takes four important attributes required in order to make the necessary connections.
The first set of two attributes deals with definitions of the consumer settings. Of these, the
ConsumerID
attribute references the name of the control on the ASP.NET page (through its ID attribute) and the
ConsumerConnectionPointID
references the ID of the object working as the connection point for the
consumer. Looking back, you find this is the

RetrieveTitle()
method shown in the following code
snippet:
<
ConnectionConsumer("Calendar Title Consumer", "CalendarTitleConsumer")
>
_
Public Sub RetrieveTitle(ByVal Provider As IStringForCalendar)
_myProvider = Provider
End Sub
The second set of attributes required by the WebPartConnection deals with the provider Web Part. The
first attribute of this set is the
ProviderID
attribute that makes reference to the name of the control on the
ASP.NET page, which is considered the provider. The second attribute,
ProviderConnectionPointID
is quite similar to the
ConsumerConnectionPointID
attribute, but the
ProviderConnectionPointID
attribute references the ID of the object working as the provider in the connection process.
<
ConnectionProvider("Provider for String From TextBox", "TextBoxStringProvider")
>
_
Public Function TextBoxStringProvider() As IStringForCalendar
Return Me
End Function
Running this page gives you the results illustrated in Figure 17-25.
If you type any text string in the text box in the provider Web Part on the page and click the button

within this control, the Calendar control uses this
String
value as its value for the
Caption
property.
This is demonstrated in Figure 17-26.
As you can see from this example, you take a lot of steps to take to make this happen, but the steps aren’t
too difficult. In this example, a simple
String
object was passed from one Web Part to another. You
could, however, use the exact same process to pass more complex objects (even custom objects) or larger
items such a
DataSet
object.
Understanding the Difficulties in Dealing with Master Pages
When Connecting Web Parts
You should note one final consideration about dealing with connecting Web Parts on your ASP.NET
pages. You might have already realized that this process gets rather difficult when you are working with
ASP.NET pages that make use of the master page capability provided by ASP.NET.
858
Evjen c17.tex V2 - 01/28/2008 2:58pm Page 859
Chapter 17: Portal Frameworks and Web Parts
Figure 17-25
Figure 17-26
You are allowed only a single WebPartManager control on an ASP.NET page. Many times, when you
are working with master pages, it makes a lot of sense to put this control in the master page itself rather
than in the content pages that make use of the master page. If you are taking this approach, it does not
make much sense to start using WebPartConnection controls within the master page. You can easily
have controls with the same ID on multiple content pages. If you do so, the references made within the
WebPartConnection control might not be meant for these other controls. For this reason, you need to

make use of the ProxyWebPartManager control.
859
Evjen c17.tex V2 - 01/28/2008 2:58pm Page 860
Chapter 17: Portal Frameworks and Web Parts
Suppose you have a master page with a WebPartManger control. In this case, the WebPartManager
control can be rather simple, as shown here:
<
asp:WebPartManager ID="WebPartManager1" runat="server"
>
<
/asp:WebPartManager
>
With this WebPartManager control on your
.master
page, you ensure this single instance manages the
Web Parts contained in each and every content page making use of this particular master page.
Next, if a content page making use of this master page is attempting to connect some Web Parts, you
must place a ProxyWebPartManger control on the content page itself. This instance of the ProxyWeb-
PartManager is where you define the connections for the Web Parts on this particular content page. This
is illustrated in the following code snippet:
<
asp:ProxyWebPartManager ID="ProxyWebPartManager1" runat="server"
>
<
StaticConnections
>
<
asp:WebPartConnection ID="WebPartConnection1"
ConsumerID="ModifyableCalendar1"
ConsumerConnectionPointID="CalendarTitleConsumer"

ProviderID="TextBoxChanger1"
ProviderConnectionPointID="TextBoxStringProvider"
>
<
/asp:WebPartConnection
>
<
/StaticConnections
>
<
/asp:ProxyWebPartManager
>
Summary
This chapter introduced you to the WebPartManager, WebPartZone, and the WebPart controls. Not only
do these controls allow for easy customization of the look-and-feel of either the Web Parts or the zones in
which they are located, but also the framework provided can be used to completely modify the behavior
of these items.
This chapter also showed you how to create your own custom Web Part controls. Creating your own
controls was always one of the benefits provided by ASP.NET, and this benefit has been taken one step
further with the capability to now create Web Part controls. Web Part controls enable you to take advan-
tage of some of the more complex features that you do not get with custom ASP.NET server controls.
You may find the Portal Framework to be one of the more exciting features of ASP.NET 3.5; you may like
the idea of creating completely modular and customizable Web pages. End users like this feature, and it is
quite easy for developers to implement. Just remember that you do not have to implement every feature
explained in this chapter; with the framework provided, however, you can choose the functionality that
you want.
860
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 861
HTML and CSS Design
with ASP.NET

When HTML was first introduced by Tim Berners-Lee, it was intended to be a simple way for
researchers using the Internet to format and cross-link their research documents. At the time, the
Web was still primarily text-based; therefore, the formatting requirements for these documents
were fairly basic. HTML needed only a small handful of basic layout concepts such as a title,
paragraph, headers, and lists. As the Web was opened up to the general public, graphical browsers
were introduced, and as requirements for formatting Web pages continued to expand, newer ver-
sions of HTML were introduced. These newer versions expanded the original capabilities of HTML
to accommodate the new, rich graphical browser environment, allowing table layouts, richer font
styling, images, and frames.
While all of these improvements to HTML were helpful, HTML still proved to be inadequate for
allowing developers to create complex, highly stylized Web pages. Therefore, in 1994 a new tech-
nology called Cascading Style Sheets was introduced. CSS served as a complementary technology
to HTML, giving developers o f Web pages the power they needed to finely control the style of their
Web pages.
As the Web has matured, CSS has gained popularity as developers realized that it has significant
advantages over standard HTML styling capabilities. Unlike HTML, which was originally con-
ceived as primarily a layout mechanism, CSS was conceived from the beginning to provide rich
styling capabilities to Web pages. The cascading nature of CSS makes it easy to apply styles with a
broad stroke to an entire application, and only where necessary override those styles. CSS makes
is easy to externally define Web site style information, allowing for a clear separation of Web page
style and structure. CSS also allows developers to greatly reduce the file size of a Web page, which
translates into faster page load times and reduced bandwidth consumption.
While the point of this chapter is not to convince you that CSS is the best solution for styling your
Web site, it will help you understand how you can leverage these technologies in your ASP.NET-
based Web applications. It will start with a brief overview of CSS and how it works with HTML,
and then move into creating Web s ites in Visual Studio using HTML and CSS. Finally, you look at
how you can use ASP.NET and CSS together.
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 862
Chapter 18: HTML and CSS Design with ASP.NET
Caveats

While this chapter includes a lot of great information about HTML and CSS, and how you can use
them in conjunction with ASP.NET and Visual Studio 2008, there are several caveats you should be
aware of.
First, because there is no way that a single chapter can begin to cover the entire breadth of HTML
and CSS, if you are looking for an in-depth discussion of these topics, you can check out the Wrox title
Beginning CSS: Cascading Style Sheets for Web Design, 2nd Edition, by Richard York (Wiley Publishing,
Inc., 2007).
Second, because CSS is simply a specification, it is up to each browser vendor to actually interpret and
implement that specification. As is so often the case in Web development, each browser has its own quirks
in how it implements (or sometimes does not implement) different CSS features. While the samples in
this chapter were tested on Internet Explorer 7, you should make sure to thoroughly test your Web sites
in multiple browsers on multiple platforms in order to ensure that your CSS is rendering appropriately
in each browser you are targeting.
Finally, the DOCTYPE you use in your Web pages can influence how the browser applies the CSS styles
includes in your Web page. You should understand how different DOCTYPES influence the browser’s
rendering process in your Web page.
HTML and CSS Overview
From the beginning of the Web, continuing to today, HTML serves as the primary mechanism for defin-
ing the content blocks of your Web page, and is the easiest way to define the layout of your Web page.
HTML includes a variety of layout tags you can use, including Table, List, and Grouping elements. You
can combine these elements to create highly complex layouts in your Web page. Figure 18-1 illustrates a
single Web page that defines a basic layout using a variety of HTML elements.
While this layout is interesting, it lacks all but the most basic styling. To solve this problem, many devel-
opers would be tempted to start adding HTML-based formatting tags. For example, if I wanted to change
the font and color of the text in the first paragraph, I might change its HTML to something like this:
<font face="Arial" Color="Maroon">
In fact, in the early days of Web design tools, this is what most of them generated when the user added
styling to their Web pages, and for a while, using Font tags looks like a great solution to the problem
of styling your Web pages.
Web developers and designers quickly learned, however, that using the Font tag quickly leads to a mess

of spaghetti HTML, with font tags being splattered throughout the HTML. Imagine that if, in the previous
example, you not only wanted to set the control and color, but some of the work needed to be bold,
others needed to be a different color or font face, some a different font size, some underlined, and some
displayed as superscript. Imagine how many font tags you would need then and how it would increase
the weight of the Web page and decrease its maintainability. Using Font tags (and other style-related
tags) meant that there was no longer a clear and clean separation between the structure and content of
the Web page, but instead both were mashed together into a single complex document.
862
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 863
Chapter 18: HTML and CSS Design with ASP.NET
Figure 18-1
Introducing CSS
The introduction of CSS to the Web development and design world brought it back to a clean and elegant
solution for styling Web pages. CSS meant a style could be defined in a single location for the entire
Web site, and simply referenced on the elements requiring the style. Using CSS brought back the logic
separation between Web page content and the styles used to display it.
Creating Style Sheets
Like HTML, CSS is an interpreted language. When a Web page request is processed by a Web server,
the server’s response can include style sheets, which are simply collections of CSS instructions. The style
sheets can be included in the servers’ response in three different ways: through external style sheet files,
internal style sheets embedded directly in the Web page, or inline styles sheets.
External Style Sheets
External Style Sheets are collections of CSS styles stored outside of the Web pages that will use t hem —
generally files using the .css extension. Visual Studio makes it simple to add external style sheet files to
your application by including a Style Sheet file template in the Add New Item dialog box, as shown in
Figure 18-2.
863
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 864
Chapter 18: HTML and CSS Design with ASP.NET
Figure 18-2

Once the Style Sheet is created by Visual Studio, it’s easy to insert new styles. Visual Studio even gives
you CSS IntelliSense when working with styles in the document, as shown in Figure 18-3.
Figure 18-3
External style sheets are linked into Web pages using the HTML
<
link
> tag. A single Web page can
contain multiple style sheet references, as shown in Listing 18-1.
864
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 865
Chapter 18: HTML and CSS Design with ASP.NET
Listing 18-1: Using external style sheets in a Web page
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
" /><html xmlns=" /><head runat="server">
<title>CSS Inheritance Sample</title>
<link href="SampleStyles.css" rel="stylesheet" type="text/css" />
</head>
<body>
<form id="form1" runat="server">
<div>Lorum Ipsum</div>
</form>
</body>
</html>
You can add multiple
link
tags to a single Web page in order to link several different style sheets into
the page. You can also use the CSS
import
statement directly in your style sheet to actually link multiple
style sheets together.

@import url("layout.css");
Using the
import
statement has t he advantage that you can alter the style sheets linked together without
having to modify every Web page in your site. Instead, you can simply link each page to a master external
style sheet, which in turn will use the
import
statement to link in other external style sheets. Note that
older browsers may not understand this syntax and will simply ignore the command.
Using external style sheets in your Web site offers several advantages. First, because external style sheets
are kept outside of the Web pages in your site, it is easier to add a link tag to all of your Web pages rather
than trying to manage the styles directly in each page. This also makes maintenance easier because,
should you decide to update the style of your Web site in the future, you have a single location in which
styles are kept. Finally, using external style sheets can also help the performance of your Web site by
allowing the browser to take advantage of its caching capabilities. Like other files downloaded by the
browser, the style sheets will be cached on the client once they have been downloaded.
Internal Style Sheets
Internal style sheets are collections of CSS styles that are stored internally in a single Web page. The
styles are located inside of the HTML
<
style
> tag, which is generally located in the <
head
> section of
the Web page. An example of internal style sheets is shown in Listing 18-2.
Listing 18-2: Using internal style sheets in a Web page
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
" /><html xmlns=" /><head runat="server">
<title>CSS Inheritance Sample</title>
<style type="text/css">

Continued
865
Evjen c18.tex V2 - 01/28/2008 3:01pm Page 866
Chapter 18: HTML and CSS Design with ASP.NET
div
{
font-family:Arial;
}
</style>
</head>
<body>
<form id="form1" runat="server">
<div>Lorum Ipsum</div>
</form>
</body>
</html>
It is important when you create internal style sheets that when you create style blocks, you make sure to
include the
type
attribute with the style tag so the b rowser knows how to properly interpret the block.
Additionally, as with external style sheets, Visual Studio also gives you IntelliSense support to make it
easy for you to add properties.
Inline Styles
Inline styles are CSS styles that are applied directly to an individual HTML element using t he element’s
Style
attribute which is available on most HTML elements. An example of inline styles is shown in
Listing 18-3.
Listing 18-3: Using inline styles in a Web page
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
" /><html xmlns=" /><head runat="server">

<title>CSS Inheritance Sample</title>
</head>
<body>
<form id="form1" runat="server">
<div style="font-family:Arial;">Lorum Ipsum</div>
</form>
</body>
</html>
CSS Rules
Regardless of how they are stored, once CSS styles are sent f rom the server to the client, the browser
is responsible for parsing the styles and applying them to the appropriate HTML elements in the Web
page. If a style is stored in either an external or internal style sheet, the styles will be defined as a CSS
rule. Rules are what the browser uses to determine what styling to apply, and to what HTML elements
it should.
Inline styles do not need to be defined as a rule because they are automatically applied to the element they
are included with. Therefore, the browser does not need to select the elements to apply it to.
866