OKCOOL

Just in case you’ve ended up in the wrong place… this post isn’t about parks, trench coats and jumping out at people starkers. I’d try Google if that’s what you’re after!

Nope, instead, Flashing relates to the idea of having a consistent way to output useful messages to a web page. It’s no secret that we’re quite keen on Ruby on Rails and for those that don’t know much about it (I’m still learning myself) there is a rather handy way to output messages to the user known as the Flash. It’s quite simple really, you add something in to the flash and the page displays it! It’s one of those things though… we were all using AJAX before it had a name but it’s only now that it’s been labeled that it has become widespread.

So how does this relate to .NET? Well, I’ve simply stolen the idea! In the past it’s been a bit of a nightmare to output error messages – it would normally involve using a validation summary or dropping a literal control on the page but now I have a nice Flash control that goes on to every page (or not) and outputs the contents of my flash.

It would be a bit of a shame to just have ripped of the RoR flash completely so I have extended it a bit (I suspect you can do this easily enough in rails though) to make it more powerful. The improvements I have made are as follows:

• You can specify a category – this is useful to have different areas of flash. For example, our new CMS has an admin panel to the right hand side and this needs admin related messages but the main page needs general messages.
• You can specify the persistence – this determines how long the flash messages stays. This has been very useful on Pushhit as some messages stay for the entire session, some only on the page that generated it and others only to the next page redirect. Internally this just determines if it’s put in to session and if it should be removed from session.
• Message type – we have 3 different types of message, Error, Succes and Info which determine how the message is rendered.

There’s three major components to my Flash implementation which are as follows:

1. FlashMessage – this is a simple data class that holds the message, category and message type. The class is marked as [Serializable] so that it can be stored in the session state server without a problem. Note. I’ve not tested the scalability or memory footprint of this in any serious way yet.
2. FlashMessages – this holds a list of FlashMessage objects and handles the persistance of messages.
3. TheFlash – this is a web forms control that loops through each flash message and outputs a list of messages with each message having a class for the type, e.g. error, info, success.

One thing I also generally do is implement our own custom page class containing a FlashMessages object which makes sure that it’s easy to output Flash messages from anywhere without having to instantiate an object.

Our flash controls are now fairly reliable and baked in to our library code to ensure we can quickly use them on all of our .NET projects. It has definately been worth the effort and means it’s one less thing I have to discuss with Mark (who takes care of CSS/Markup).