Entries from July 2005 ↓

The web has come a long way in the past few years, but it is still hindered greatly by the methodology of the “previous generation” of web-designers. People are still designing with the mentality of serving everyone with a page that is specifically tailored to suit their particular browser and operating system. While this did get the job done originally, it was most certainly a lot more work than it needed to be. That’s why I find the idea of generating one (and only one) document to serve all users very interesting. Most browsers are conforming to standards in some way shape or form, the majority support CSS2 and XHTML 1.1 and the ones that don’t (mostly) degrade gracefully. It’s no longer about serving a page that is pixel perfect on every system; it’s about making sure all users get a good experience from your site.

Another branch of this takes the form of Accessibility. Accessibility has recently been highlighted by governments as a priority for websites; the US and UK both have their own take on the situation with relating laws and amendments. It basically boils down to any website that is providing a service should have a bare minimum of accessibility; otherwise they are discriminating against their less able customers. This means businesses are required, by law, to provide for all their customers (whether or not they have disabilities). Just as you would expect a shop to provide wheelchair ramps for disabled shoppers, you should expect pages to be designed to aid disabled web-users.

Recently I equipped my self with a screen-reader (JAWS) and was appalled — but not particularly shocked — at the amount of sites that are simply unusable with anything other than a standard browser. Most pages are so full of invalid markup that the screen-readers simply mumble on continuously and any actual content is undecipherable. If websites complied to the standards then their experience would be tolerable at the very least. Unfortunately the majority of website designers simply do not know (or often care) about creating accessible pages.

Note: Screen-readers, for those that don’t know, take a web page and read it out using a synthesised voice. A perfectly accessible site would read the same as a printed document.

One of the largest problems with the way pages have been designed in the past has been using the supplied tags for their appearance rather than their actual purpose. The <b> tags have been used to create bold headings, the <font> tags used to change styles of fonts and worst of all the <table> tags for layout. This means when a screen reader parses these pages it emphasises the wrong words and spouts nonsense when encountering these convoluted tags. What a properly designed page would have is a distinct separation of content and layout, of HTML and CSS. The HTML document should use be structured like a standard plain text print document; with appropriate headings, sub-headings, lists and paragraphs. These tags can then be styled using CSS to any manner to which they like. So when a screen reader encounters this page it reads the unstyled version; a perfectly formed document.

That’s the end of my little rant, maybe together we learned something.

In my previous post I talked about my exception logging system that I laid to rest. Fortunately for me that doesn’t mean my applications are logless, quite the contrary. I’ll explain…

When I came to terms with my logging system being inadequate and hard to maintain, I began looking for a replacement. To my delight I came across ELMAH written by Atif Aziz. ELMAH is basically a couple of HttpModules and a HttpHandler that intercept any unhandled exceptions from within your application and log them. This is where the fun begins…

You can download/create extensions that enable you to save your logs to wherever takes your fancy. There is a SQL Server writer, an XML file writer and I believe an MySql writer too. I’m currently using the XML writer simply because connecting to the SqlServer may be one of the possible exceptions raised. I’ve been running ELMAH now for 2 weeks and have had no issues at all; especially no write-permission related ones!

This MSDN Article by Scott Mitchell was my manual for setting up ELMAH, not that it was hard. That article can explain it much better than I every could.

Once you’ve got it all set up and assigned a location to the HttpHandler, you can navigate there and be presented with a log viewer. Details of the exception and even the actual yellow screen that occurred too (through a dump of the html) can be accessed though that screen. The thing that got me really interested was the ability to subscribe to an RSS feed of your log! Now I no longer have to spend 40 minutes on the phone trying to decypher what really happened when the client claims they “didn’t touch a thing, it just crashed on its own”. All you have to do is (in your favorite feed reader) enter your log viewer path with “/rss” added to the end (e.g. http://www.mysite.com/Logs/View.aspx/rss). Then you can get all the same details as navigating to the page, without actually having to do anything! Oh yes, life is good.

There was one thing I had to come to terms with while setting up ELMAH. That is the fact that only unhandled exceptions will be logged, so that meant most of my try-catch blocks were causing my exceptions not to be logged. The solution to this was to remove the blocks that weren’t performing any specific function except that of gobbling up the exception and firing out a generic error message. I felt uncomfortable with this at first, as I was letting exceptions run riot but then I realized there’s not much point in handling exceptions if I can’t actually do anything to correct the error that occurred. So letting them go unhandled is probably the best cause of action (what exactly can be done if your SqlConnection won’t connect? It’s not like you can just connect to your mirrored SQL Server). So those exceptions are bubbled up to the page and then ELMAH captures and logs them. Using the customErrors section of the web.config you can present your users with a generic error page to stop them from seeing the nasty yellow screen.

That my friends is the general gist of ELMAH…

Something I’ve always been tinkering with for my ASP.Net applications has been exception logging. I often get irritated when users (or applications) supply me with misleading or incorrect error messages, or at least incorrect directions of how to recreate the error.

I worked for quite some time trying to create a Logging system that would cater for my needs, and I got quite close to doing that. I created a small go-between object for the Trace and Debug logging and wrote that to my own XML file. The idea behind it, of course, was to make it easier for my self in debugging problems, if I could supply my self with all the data that I know I would require to trace an issue then, in theory, I could correct it much more quickly. This took me quite some time to create and of course was not perfect.

There were a few major (a.k.a. Huge) issues with my system, firstly the logger would only interact with your code wherever you explicitly told it to. Basically you had to write extra code wherever you wanted to log an exception. This was neither friendly nor desirable. The next issue was access rights for the XML files; this reared its head in a few shapes and forms. One of the instances didn’t occur very often but was a pain when it did; the writer was rejected write access due to another instance of itself actually writing to the file. I remedied this by making the writer wait until the other was done; this of course had performance implications though, having to stop everything within a page while the log writer sits idle. The other time it was an issue was whenever I wanted to archive the logs I had to wait until no other instances were accessing it, this also involved waiting but it takes longer to rename a file and create a new one than it does to simply amend a file.

The problem of having to explicitly declare any usage of the writer was the deciding factor in me binning my writer. Sad as it is to see something that I spent a fair amount of time creating deleted, it’s always slightly reassuring when you’re moving onto a product that is fully tested and working and also includes all source code! More on that soon though…