Slight Difference for ASP.NET 2.0
I originally wrote this article for ASP.NET 1.x. The concept and implementation still works just fine with ASP.NET 2.0 with one change: You must store the code-behind page for your MessageDisplay.aspx
page in the APP_CODE
directory rather than in the same directory as your ASPX page so that the page class (MessageDisplay) is globally accessible to your application.
In ASP.NET 2.0, you can no longer globally access individual ASPX page classes by direct reference because they compile into dynamic assemblies at runtime. This mean you cannot access the static MessageDisplay.DisplayMessage()
method from your application. However, any class stored in the APP_CODE
directory gets compiled into a separate assembly that is implicitly referenced by the ASP.NET application and is thus globally accessible.
The sample projects I've provided for download
include both ASP.NET 1.x and 2.x versions.
You've Got Messages!
You now have a generic message display implementation that you can call from anywhere in your application with a single method call. You can even set up multiple message display pages by providing a specific page name to display. As long as the pages derive from wwMessageDisplay and they include the required controls to display the header and messages you're ready to go.
|The hardest part of the implementation is fixing up the HTTP paths to make sure all embedded links point at the right relative paths.|
I use this class all over the place. All my error handling goes through this class as well as many administrative forms that do not work well for the postback mechanism. For example, many of my applications include delete functionality where the main operations are handled through plain postback, but at the end of a delete operation I display a message of the final status that lets the user know the operation has completed.
"Invoice Number: " + Invoice.InvNo +
"<hr>has been deleted.",
This is much nicer than just redirecting-you're giving some feedback first, then going to another location. Also in this case where a deletion occurs, it's hard to post back to the current page. The invoice no longer exists, and you can't display a message on that invoice page itself since there's nothing left to show. Instead you have to go somewhere else and it's nice to be notified first that the operation completed before moving on. Being able to do this with a couple of lines of code is very convenient.
I hope that this article has given you a few tips and insights in to how you can build front-end routines to ASP.NET pages. In essence, I've shown you a generic way to call an ASPX page through a simple method. If you look at this approach you might find a few other places where a single method interface provides efficient access to frequently used pages that require dynamic data to be passed in and displayed. You can download the source code for this article
to get a head start on the code.