Beginning ASP.NET 2.0 With CSharp (2006) [eng]

Chapter 5

Figure 5-28

The code that handles the theme switching is explained in detail in Chapter 11, because it involves an understanding of several techniques that have not yet been covered in the book. However, in the following Try It Out, you can see how the themes are applied to the Wrox United site, and it steps through the most interesting bits in the theme definitions for the Wrox United site.

1.Open your local copy of the Wrox United application — this should be stored within your

C:\BegASPNET2\WroxUnited folder.

2.Press Ctrl+F5 to run the site and you’ll be taken to the main front page in its default color scheme. In the login box near the bottom of the left-hand column, log in as the user Lou, password lou@123. In the box that appears below the login box, click the Modify Account link, as highlighted by the hand-style cursor in Figure 5-29.

3.In the screen that appears (see Figure 5-30), select the Wrox Blue theme from the Theme dropdown list and click Save Changes.

4.Click the Home link at the top of the menu at the side of the page to go back to the front page of the site and you’ll now see the site rendered with the blue theme, as shown in Figure 5-31.

You might not be able to see the difference that clearly in a printed book, but because it’s quite easy to try out for yourself, give it a go and see the changes for yourself.

168

Styling with Themes

Figure 5-29

Chapter 5

Figure 5-31

How It Works

This example demonstrated the theme-switching capability of the Wrox United site, which is something you look at in a lot more detail in Chapter 11, but the important part of the exercise to concentrate on here is the styling of the site itself.

Many styles are in use on this site, so look at the Wrox Red theme first and see how the styling is applied to the elements on the page using this theme.

The Wrox United red skin (the WroxRed.skin file within the WroxRed Theme folder) is included with the rest of the code for the site (available at www.wrox.com). The following listing shows some of the styles defined in this skin file:

<asp:Label runat=”server” ForeColor=”#000000” BackColor=”transparent”></asp:Label>

<asp:TextBox runat=”server” ForeColor=”#000000” BorderWidth=”1px” BorderStyle=”Solid” BorderColor=”#ff0000” BackColor=”Transparent”></asp:TextBox>

<asp:Button runat=”server” BorderStyle=”Solid” BorderColor=”#ff0000” BorderWidth=”1pt” ForeColor=”#000000” BackColor=”#ffe5e5”></asp:Button>

<asp:HyperLink runat=”server” Font-Underline=”True” BorderStyle=”None”>

</asp:HyperLink>

170

Styling with Themes

Notice that there are specific style definitions for Label, TextBox, Button, HyperLink, and Calendar controls, which means that every instance of a control of each of those types will be styled as defined in this skin file.

Here’s the TextBox definition:

<asp:TextBox runat=”server” ForeColor=”#000000” BorderWidth=”1px”

BorderStyle=”Solid” BorderColor=”#ff0000” BackColor=”Transparent”></asp:TextBox>

The TextBox has been styled so that it has a thin solid red border around it. Note that the value specified for the BorderColor attribute doesn’t actually say “red,” but instead it uses the hexadecimal representation of a pure, bright red color.

The hash symbol (#) indicates that the color to be applied is provided as a hexadecimal value. The next two characters control how much red to add to the control, from 00 to FF. The next two characters control the level of green to apply, and the last two control the level of blue. The hexadecimal value 000000 represents a pure black (none of each color), whereas the value FFFFFF renders as white (all of every color).

The hexadecimal counting system (sometimes known as Base 16) means that the hex value FF corresponds to the decimal value of 256. With 256 different values for each component, that enables you to choose from one of 16 million possible color values!

The Wrox Red theme also has an associated CSS style sheet, WroxRed.css, which is also available in the code for download. The following is an extract from this file:

html, body { margin: 0;

padding:0 5px 0 5px; background-color: #f00; color: #000;

}

title { color: #f66;

}

#nav {

background-color: #f00; width: 20px;

float: left; margin-left: -1px; padding: 10px;

}

#content { padding: 10px;

margin-left: 230px; width: 100%;

}

171

Chapter 5

The styles in use in this theme define some simple color and positioning for some of the elements used on the site. The #nav definition and the #content definition are used to match all elements on a page with an ID set to nav or content, respectively, rather than specifying the class attribute, or specifying a specific element type to style.

Styling and Layout Best Practices

The concepts discussed in this chapter can be used for both good and evil. You can have as many style definitions in your site as you like, but if you have little or no sense of style, you could make a big mess of things. And style is nothing without layout — the two go hand in hand. Pages need to be structured sensibly so that any user can view and understand what you’re trying to tell them. Now that you’ve grasped the basics of styling and presenting a site, the two concepts you need to learn about now are usability and accessibility.

Usability

Usability is all about keeping users on your site, and giving them the best possible user experience while they browse. Users want to see prompt responses to their requests, they want to be able to find what they want, and they want to be able to understand what the site is all about. A site that has fifteen fonts on it will appear cluttered, hard to read, and most likely look like it was put together by someone who’d never spent time reading content on a web site.

The goal of every web development team is to make a site as usable as possible, which requires developers working together with designers to provide an attractive and intuitive user interface. This is where you can start to employ the techniques discussed in this chapter. The core principles of usability are as follows:

Learnability: Design the user interface so that it takes a minimum of time for a first-time visitor to understand the design and use the site.

Efficiency: Make the site efficient so that experienced users can accomplish tasks swiftly.

Memorability: A user should be able to remember how to use the system next time they come to visit.

Bugability: Squash those errors where possible, and if errors occur, make them user-friendly and recoverable.

Satisfaction: Users should like and enjoy using your site.

Usability is an art that has been written about by many people, but the main site you should refer to when it comes to usability guidelines is www.useit.com/, which is the web site owned by Jakob Nielsen. All developers should spend some time looking in to this area and gain some key insights into making your sites really effective.

Accessibility

Accessibility is all about making sites accessible by all users. For example, web users who are partially sighted access the web with the assistance of a screen reader, which reads the contents of a web site aloud. Alternatively, these users could have their screens set to a much lower resolution, where most

172

Styling with Themes

sites would be unable to fit on the screen. At another end of the spectrum, you could also find mobile users connecting to the web using a Pocket PC device that’s only capable of displaying 320 × 240 pixels of information at one time. The browsers used on different devices like Pocket PCs employ some great techniques for scaling images to make a site fit on a screen. You could also find yourself having to cater to users who have very limited-functionality browsers — perhaps browsers that don’t allow the use of JavaScript for client-side code, or that don’t display images on a page to save on bandwidth. If an image were missing from a page, it would be nice to know what the image was supposed to represent to give it some context in the absence of the image itself.

At the core of accessibility are some facts that will help you to make your sites as accessible as possible. For example, if you have a screen reader reading out your source code, you should always include an HTML alt attribute on your images, so that the screen reader can describe what the image represents. You should always provide code that can render your site on browsers that don’t support HTML frames using the <noframes> element, and you should avoid, where possible, using many levels of nested HTML tables to lay out a site, because a screen reader will read out the contents of every cell and row.

Many different guidelines are available for making a site accessible, and the best place to start reading is the www.w3.org/WAI/ site. This site is the home page for the Web Accessibility Initiative and is packed full of useful and important advice.

Despite the existence of myriad resources, the vast majority of developers in the world have never given a second thought to making a site truly accessible. Many more have thought about it and made some changes to their site in an attempt to make it more accessible, but building truly accessible sites is actually quite difficult.

Take for example the Wrox United web site. This book concentrates on teaching you how to build ASP.NET web sites. The main focus is teaching what is possible, the techniques you can use, and how you can get results quickly. To make this site truly accessible would take a fair bit more time, and perhaps that would be the topic for another book.

Learn as much as possible about building accessible web sites for any public site you develop, because it’s actually illegal (though not often enforced) to only provide an inaccessible web site, as described in Section 508 (see www.section508.gov) in the U.S., and the Disability Rights Commission’s (DRC)

Disability Discrimination Act (DDA) Code of Practice (www.opsi.gov.uk/acts/acts1995/95050-- c.htm) in the UK. Prosecution for inaccessibility is quite rare, but because it’s entirely possible to design accessible web sites, it’s worth adding accessible web design to your skill set for both those with disabilities, and for your own professional reputation.

Summar y

This chapter discussed all of the different ways of styling a page and its elements, and demonstrated numerous methods for controlling look and feel. The new skinning and themeing capabilities of ASP.NET 2.0 provide you with a great way to combine all available techniques into one easily applied package.

This chapter discussed the following:

How to apply style attributes to elements

173

Chapter 5

How to move style attribute information into <style> sections in a page, then into a separate CSS file

Creating ASP.NET themes and applying them to pages

The differences between Customization themes and Stylesheet themes

Integrating themes and CSS

Applying a consistent style to all pages in a site

The issues of usability and accessibility and why they are so important in today’s Internet world

The next chapter moves on to discuss the issues of raising and handling events in code, as you are introduced to the concept of a postback-driven architecture.

Exercises

1.You have an ASP.NET Label control on a page. The label has a font-italic=”true” attribute, and a CssClass=”maintext” attribute:

<asp:label id=”myLabel” CssClass=”maintext” font-italic=”true”

text=”This is a label”></asp:label>

The page has an associated CSS style sheet (not associated with a theme) that defines a

.maintext style class. This style class has the following attributes:

.maintext

{

color: Navy; font-family: Verdana; font-weight: Bold; font-style: normal;

}

How will the label appear when it is rendered?

2.You add a Theme=”ExerciseTheme” to the preceding page. You place the CSS style sheet from the previous exercise within the ExerciseTheme theme folder. How will the label control appear now?

3.You define a skin for all labels within the ExerciseTheme theme folder and specify the following attributes:

<asp:Label CssClass=”maintext” runat=”server” font-italic=”false”></asp:Label>

How will the label appear now?

174

Chapter 6

process actually works: what happens when you fire up your browser and type a URL into the address box, what happens when you press a button on a page, how the web server keeps track of the pages, and so on.

HTTP works by having a set of commands that browsers send to a web server. The two most common of these commands are GET and POST. The GET command is what a browser sends when a web page is to be fetched — it’s what happens when you type a URL into the browser’s address bar and press Return; it simply means “get me this web page.” The POST command is for when something is to be sent back to the web server — for example, when you fill in a form and press a button. In reality the POST command actually fetches a page, but it also sends the form data back to the web server.

You don’t need to know the rest of the HTTP commands or how any of them work in detail, but it’s useful to know the terms and to understand that HTTP is very simple.

HTTP Is Stateless

One of the things you have to understand about HTTP is that it is stateless, meaning that it retains no knowledge from one request to the next. So when you request a page from a web server, the page is sent to you, and the server immediately forgets everything about you; each request stands alone. HTML doesn’t help much either, because it’s simple a language for the representation of the contents of the page; like HTTP, HTML doesn’t retain content. For example, consider a simple web page that has a text box and a button. In your browser you enter some text and press the button. The data you entered is sent back to the web server, the web server process the page (making changes as necessary), and the page is sent back to the browser to be redisplayed. However, because there is no retention of data, the text box comes back empty — it’s as though the web server has forgotten your text.

Why is this a problem? Well, it poses some real issues when writing applications, because very often you want some form of data retention. For example, consider the checkout page at an online store, such as the one at the Wrox United online shop, as shown in Figure 6-1.

Figure 6-1

The checkout involves several steps, each of which requires users to supply some form of information: making sure they are logged in, checking their address, and authorizing payment. As far as HTTP is concerned, each step is a separate request from the user; the page loading is one request, pressing the Next button is another request, and so on.

176

Events and Code

When you fill in some details on a page and press a button, that information is posted back to the web server (the term posted derives from the actual HTTP POST command used). When you reach the last of the checkout steps, you need all of the information entered by the user, not just the data supplied with the last step. Because HTTP and HTML don’t retain this information for you, you have to store it yourself. In non-ASP.NET environments this can be quite complex and time consuming, but luckily for us the server controls are clever; they retain their state across postbacks. This means you don’t have to do anything special; if you press a button to post the information back to the server, when the page is refreshed the text boxes still have their data. This is one of the big differences between standard HTML and server controls, and is one of the reasons why we use server controls.

The server controls remove even more of a burden from us. Consider the checkout page shown earlier, which has several text boxes, and that’s only one step; there’s also the login details, plus the credit card details, plus the management of the steps themselves. Server controls are used for all of the text entry, but there is also a Wizard control, designed specially for use in situations like this. It manages the steps, creates the menu of steps on the left, and provides the Previous and Next buttons. All you have to do is define what you want within those steps. When you get to the last step everything the user has typed in is available, and the order can be processed.

Server-Side Events

So far you’ve seen a very simple view of what happens when you interact with a web server — you press a button and something happens. So what is it that actually happens on the server, in your ASP.NET page? Well, simply put, there are a number of events that run; some that always run, some that only run depending on what the user has done (which button they’ve pressed), and some that run due to other actions, such as data being changed. These events are ASP.NET’s way of letting you know something has happened, and they allow you to take some action. For example, all ASP.NET pages have an event that runs when the page loads, and you can place code within this event to perform some action. Buttons have an event that runs when you click them, lists have an event that runs when you select a list item, and so on, and these events are what give you the power to control how the web page reacts to the user.

Before digging into the code, some terms need explaining. When an event happens it is called firing or raising. That is, the event is raised or the event is fired. Both terms are valid, and which you use is a matter of preference (I prefer raised, because fired always makes me think of a poor little event being stuffed into a cannon at a circus before being launched into a tiny net to amuse the crowd). Both terms are used regularly in the .NET documentation and on various online sites and articles.

The code that is run when the event is raised is called the event procedure or event handler. Any code you put in here becomes part of the event procedure and runs when the event is raised. For example, consider a page with two buttons. Each of these buttons could have its own event procedure, while there is a separate event procedure for when the page loads, as illustrated by Figure 6-2.

Figure 6-2 shows three event procedures. This first is the Page_Load event, which is raised by ASP.NET when the page loads, and allows you to prepare the page for the user, perhaps fetching data from a database.

The other two events are generated by the user when a button is clicked; each button has its own event handler. For example, the first button might save some user-entered details, whereas the second button cancels user-entered details.

177