To bind these functions to the Web form, you simply insert a CustomValidator control and set two new properties ClientValidationFunction and OnServerValidate.

In the previous example we have decided to use a server-side function as part of our validation, and set the OnServerValidate property equal to the server-side function ValidateSubscriptionServer. We also have enabled a client-side function, by setting the ClientValidationFunction property equal to the client side function,

ValidateSubscriptionClient.

ValidationSummaryx

The last control that is useful for validation is the ValidationSummary control. This control provides you with the option of listing all of the validation errors in a consolidated list for the user, rather than displaying each error message next to the field where the error actually occurred. To use the control, simply plug a ValidationSummary control somewhere on the page your user is likely to reference when reviewing problems with validation:

<ASP:VALIDATIONSUMMARY

ID=”valSummary”

SHOWMESSAGEBOX=”False”

DISPLAYMODE=”List”

HEADERTEXT=”Please correct the following errors.” SHOWSUMMARY=”True”

RUNAT=”SERVER”>

</ASP:VALIDATIONSUMMARY>

The control will automatically display all relevant validation errors in a consolidated area on the page. If you do not want the individual control errors to display, you will need

to set each validation control ErrorMessage property to an empty string. Setting the ShowSummary property to False, will prevent the display of each control’s error message. Instead, only the content of the HeaderText property will be shown.

In addition, you can choose to display error messages in a pop-up message box by setting the ShowMessageBox property of the ValidationSummary control to True. Be aware that this will only work properly when used in Internet Explorer 4.0 or higher.

The DisplayMode property can be set to List, BulletList, or SingleParagraph to modify the manner in which the list of errors is handled.

REVIEW

With the use of these controls, you should now be able to eliminate a tremendous amount of clientand server-side validation code previously required when developing ASP pages. Additionally, the ability to construct your own clientand server-side validation controls should provide you with all the flexibility you need to handle 90 percent of your business requirements.

S E S S I O N

12

Maintaining State in ASP.NET

Session Checklist

Understanding the differences between in-process and out-of-process state maintenance

Implementing ASP State Server or using SQL Server for state maintenance

Using cookies in user state maintenance

In this session, we will cover the key innovations in state maintenance available in ASP.NET, and demonstrate how these innovations will enable you as a developer to take advantage of the latest in state management to support highly scalable and redundant

Web applications.

In ASP.NET, we have optional configuration settings that enable us to select the type of state maintenance we perform, but still allow us to use the familiar methods of state variable access from ASP. In fact, we will not have to change our legacy code to take advantage of the ASP.NET enhancements over ASP with regards to state maintenance. The key differences lie in the way session state management is handled. In ASP, sessions are by default stored

in process, which creates significant headaches for developers who develop Web sites that become extremely popular. As the number of users balloon, it becomes apparent that all of those session values used for personalization and customization are killing application

performance — and that the possible remedies are limited and costly. In ASP.NET, most if not all of these issues are now very nicely handled using out-of-process state management.

Maintaining State Out of Process for Scalability

In this section, you’ll learn how the previously mentioned improvements can be of tremendous help to developers who are implementing applications that require a high degree of scalability.

In ASP, a Session object is created and maintained on the Web server from which the page is initiated. In a Web page (for example, somepage.asp) running on server Foo, the embedded ASP code:

<% Session(“MyFavoriteBeach”) = “Trestles” %>

will cause the variable MyFavoriteBeach to be stored in the memory of server Foo. This variable and all others created during the user session are persisted across multiple Web pages. If you need to retrieve the user’s favorite beach, you could simply use the embedded ASP code, for example:

<% =Session(“MyFavoriteBeach”) %>

One problem with this approach is that if server Foo crashes or otherwise goes down, all session information is lost, never to be recovered. A second problem with this approach is that it is extremely difficult to share session values with other ASP pages running on other servers. The third problem with the old Session object is that it requires the user’s browser to support client-side cookies.

All of these factors create massive headaches for ASP developers attempting to build applications that will scale efficiently and support application redundancy, load balancing, and clustering effectively. You are forced to try software solutions such as Windows Load Balancing Services (WLBS), Network Load Balancing clusters or hardware solutions such as Cisco LocalDirector. Unfortunately, these solutions are really designed to handle request-based load balancing where maintaining state on the application server is not a requirement. When you need to use session-based load balancing and store state on the application server, you have to take tremendous performance hits with WLBS by turning on the Affinity option, or if using LocalDirector you have to implement the sticky command which has the same effect — huge performance degradation. In other words, if you modify either LocalDirector or the WLBS to use session-based load balancing, then the benefits of request-based load balancing are eliminated. These options slow the system down by requiring them to maintain a user-to-server mapping and perform a lookup upon each request. It also decreases your ability to provide fault tolerance.

The result of these solutions is like buying a Ferrari and then limiting it to drive around town in stop-and-go traffic at 20 mph, rather than allowing it up on the interstate where it could fly!

The only other way developers can support session maintenance in a Web farm scenario is to do a ton of custom coding, use a back-end database, and then retrieve the session information through the use of cookies; or hidden-form data; or by URL munging the data.

With ASP.NET, Microsoft has gone to great lengths to ease this burden and make our lives as developers much, much simpler! We now have built-in out-of-process and in-process methods to handle state maintenance in ASP.NET, as well as a choice of using client-side cookies or munging the session id.