SP.NET reduces the need for generic message pages with its postback-based metaphor. Because most pages post back to themselves rather than going off to other pages, you can often redisplay messages on the original page with a message or error header. Not only is this convenient to code with .NET by simply adding a label or even a custom error display control to show the message, but it’s also better for the user who sees the message in the context of the operation that produced the error or action that caused the message.

Creating messages in your Web application should be quick, easy, and most importantly, consistent.

They should look like they belong with the rest of the application even if an error occurs. How often have you created a new page to display simple text or a notification message to your users? Wouldn’t it be better if you could reuse an existing template and simply pass in a few parameters to tell it to render an application-specific message? In this article I will show you how to create a reusable Message Display class that reduces displaying messages generically in your application to a single line of code.

However, there are still a number of occasions where the ASP.NET postback mechanism doesn’t lend itself well to message and error display. In these situations, a generic message display page comes in very handy. A generic message display is a simple, reusable page template that your application can call as a single method call by passing a couple of parameters. You can use it for these types of situations:

• Global error messages. Errors captured in the Global.asax Application_Error event generally end up displaying a generic error page. Rather than redirecting to a completely static page, you can provide customized info via a generic display page that may contain a semi-static message, or for administrators, detailed error information.
• Simple confirmation pages. There are still a number of forms that do well with simply having a confirmation page that says, “Thank you for your submission.” ASP.NET will always post back to the same page, but in many instances there’s nothing to display when you go back. For example, when you delete a record or you need to display a simple, but lengthy generated result. Although you can do this with a Redirect() you really don’t want to create a new form for each message, nor do you always want to go somewhere else without giving the user some feedback first.
• Redirection situations where you need cookies. In many applications there are login scenarios where users are either automatically logged in or logged in through a login form. Although Forms Authentication can handle some of these scenarios, it’s often not granular enough to provide the functionality needed. In some login situations you need to forward to a new page, but at the same time you also need to store a Cookie (for permanent record), so you can’t use a Response.Redirect(). Instead, use an intermediate Display page that includes a META refresh tag to handle the forwarding either automatically or with an optional link. This approach makes it possible to pass Cookies forward to the next page.
• Quick dynamic display of HTML data. Because this class uses predefined controls, it’s easy to pass in a header and a message-optionally in HTML format to easily create an HTML display. You can use this for debugging scenarios or while testing code.

Using the Class
The primary purpose of this class and template is to display stand alone messages easily and consistently from within your application. To implement this functionality I created a generic reusable class that you must subclass for each application you build. The base class consists of a non-visual Web Form class and it relies on the concrete implementation and the ASPX template of the subclassed Web Form to provide its visual interface.

	?
Figure 1: Displaying a Generic Message Page. It takes only a single call to the DisplayMessage() method with a Header and Message body to generate a parameterized, generic message page from anywhere in the Web application.

The concept is simple: You add a new Web Form to your application and subclass it from the wwMessageDisplay base class. The HTML layout/design for your message page is customized to your application and reflects your own theme and layout. You must also add a few required labels that get dynamically filled in with the data you want to display. This includes the header and body as well as the title and optional redirection directives. Beyond that, the form can be of your own design to match your Web application’s look and feel. Figure 1 shows an example of an application-specific error message displayed in my Web Store application for the West Wind site that uses the custom MessageDisplay form created for the application.

Once you’ve designed your HTML form and subclassed it from wwMessageDisplay, calling this custom message page is as simple as making a static method call with at least two parameters to specify the header and message. Assuming the custom class and ASPX page is called the by default name “MessageDisplay,” (MessageDisplay.aspx) you can call this from anywhere in your application.

   MessageDisplay.DisplayMessage(      "We're sorry, an error occurred",      An error occurred in the application...");

Places you can call this from include: an ASPX page event, within an ASPX page expression (<%= %>), and even from an HTTP handler or module. The call will take care of the current request, displaying the message page, and then exit. You don’t need to issue Response.End() to finish. It is implicit in the DisplayMessage() code.

You pass in a header message and the body text for the page. Both can contain HTML markup to allow you to embed links or formatting if necessary as Figure 1 does with the link back to the Web Store Home Page. Additional overloads of the DisplayMessage() method allow you to specify an explicit ASPX page (in case you have more than one “message template page” in your application) and you can pass in a URL to automatically redirect to after a specified interval. The redirection is performed with a META Refresh tag in the generated HTML output.

As you can see in Figure 1, the page is customized with the look and feel of the main application. It has the toolbar, links, and page footer of the original application. The layout is provided by the custom Web form the developer creates. This form is required to contain at least a Header and a Message label control in order to work. The template HTML in this example includes several optional user controls (the toolbar, footer and links boxes), but the layout is completely up to you and your application’s look and feel.

In order for the information to display the HTML Template, your ASPX page requires that a couple of expressions and label controls exist in the page. Listing 1 shows the ASPX HTML source for the page above. The required portions are marked in bold. Only a few things are specific to the MessageDisplay routine.

• lblHeader label. This is where the header text is displayed. In Figure 1, this is the Application Error message in the blue bar.
• lblMessage label. This is the label that receives the main message text. This text should be in HTML format or plain text (in which case it just flows as a single paragraph).
• lblRedirectHyperLink label. If you’re using a Redirect link, this label indicates the page you are redirecting to. The page should automatically redirect to this link when the timeout is hit, but if it doesn’t (if the browser doesn’t support it or has it disabled) it’s there to click on.