A new version of the MvcPaging component is available via NuGet with the following changes:

• Added ItemStart and ItemEnd properties to IPagedList (Displaying items {ItemStart} – {ItemEnd}).
• Non-canonical url’s for page 1 (https://github.com/martijnboland/MvcPaging/issues/2).

So the core library hasn’t changed much, and in all honesty, I think it’s pretty much done. Please leave a reply if you think otherwise.

What did change substantially is the sample application. It was still very much ASP.NET 1.0 with WebForms views. This is now a proper ASP.NET MVC 3 application with Razor views and the default ASP.NET MVC 4.0 template for look & feel.

The sample application can be found at GitHub.

In almost every application, feedback from the application to the user via notification messages is required.

For some strange reason, we don’t have a standard way in .NET web applications for dealing with this kind of messages and I find myself hacking some half-baked solutions over and over again. Starting from today, this must end! In this post we’re going to find a solution for ASP.NET MVC 3.

One single way to display messages

This is the one and only requirement:

In every scenario I want to be able to call ShowMessage() from my controller action and the message appears on the screen.

ShowMessage extension method

To have a ShowMessage method in every controller action, we could implement it in a base controller class or create an extension method. Let’s try an extension method:

public static void ShowMessage(this Controller controller, MessageType messageType, string message, bool showAfterRedirect = false)
{
    var messageTypeKey = messageType.ToString();
    if (showAfterRedirect)
    {
        controller.TempData[messageTypeKey] = message;
    }
    else
    {
        controller.ViewData[messageTypeKey] = message;
    }
}

All this method does is take a message type enum (Success, Warning or Error) and a message and store it in either ViewData or TempData, depending on the flag ‘showAfterRedirect’. TempData is for Post-Redirect-Get situations.

We can now call ShowMessage(). With this solution it’s only possible to store one type of message per request, but that should be enough (even more than one message is already troublesome).

RenderMessages HTML Helper

Creating messages is one thing, but what about displaying them? It’s also easy. Enter the RenderMessages() HTML helper:

/// <summary>
/// Render all messages that have been set during execution of the controller action.
/// </summary>
/// <param name="htmlHelper"></param>
/// <returns></returns>
public static HtmlString RenderMessages(this HtmlHelper htmlHelper)
{
    var messages = String.Empty;
    foreach (var messageType in Enum.GetNames(typeof(MessageType)))
    {
        var message = htmlHelper.ViewContext.ViewData.ContainsKey(messageType)
                        ? htmlHelper.ViewContext.ViewData[messageType]
                        : htmlHelper.ViewContext.TempData.ContainsKey(messageType)
                            ? htmlHelper.ViewContext.TempData[messageType]
                            : null;
        if (message != null)
        {
            var messageBoxBuilder = new TagBuilder("div");
            messageBoxBuilder.AddCssClass(String.Format("messagebox {0}", messageType.ToLowerInvariant()));
            messageBoxBuilder.SetInnerText(message.ToString());
            messages += messageBoxBuilder.ToString();
        }
    }
    return MvcHtmlString.Create(messages);
}

It iterates through all possible message types, tries to find a message in either ViewData or TempData and creates a div with the message in it.

Put the helper in the Layout page, add some css classes (.messagebox, .succes, .warning and .error) and we’re all set.

What about AJAX?

Now this is getting tricky. In our AJAX actions, we can still call ShowMessage(), but how should the message be displayed if we only return some JSON data or a partial view? One solution would be to wrap all AJAX results in a special JSON view result with the notification messages and the original result embedded. Drawback is that we have quite some work to do on the client-side to handle all this.

HTTP headers to the rescue

I discovered a very nice solution on StackOverflow: use custom HTTP headers to store a message. With the help of a global action filter we can check if there are messages in the ViewData dictionary and when the request was an AJAX request, copy the messages to a custom HTTP header.

/// <summary>
/// If we're dealing with ajax requests, any message that is in the view data goes to
/// the http header.
/// </summary>
public class AjaxMessagesFilter : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if (filterContext.HttpContext.Request.IsAjaxRequest())
        {
            var viewData = filterContext.Controller.ViewData;
            var response = filterContext.HttpContext.Response;

            foreach (var messageType in Enum.GetNames(typeof(MessageType)))
            {
                var message = viewData.ContainsKey(messageType)
                                ? viewData[messageType]
                                : null;
                if (message != null) // We store only one message in the http header. First message that comes wins.
                {
                    response.AddHeader("X-Message-Type", messageType);
                    response.AddHeader("X-Message", message.ToString());
                    return;
                }
            }
        }
    }
}

Finally the message in the HTTP headers are displayed with a little bit of jQuery:

$(document).ready(function () {
    handleAjaxMessages();
});

function handleAjaxMessages() {
    $(document).ajaxSuccess(function (event, request) {
        checkAndHandleMessageFromHeader(request);
    }).ajaxError(function (event, request) {
        displayMessage(request.responseText, "error");
    });
}

function checkAndHandleMessageFromHeader(request) {
    var msg = request.getResponseHeader('X-Message');
    if (msg) {
        displayMessage(msg, request.getResponseHeader('X-Message-Type'));
    }
}

function displayMessage(message, messageType) {
    $("#messagewrapper").html('<div class="messagebox ' + messageType.toLowerCase() + '"></div>');
    $("#messagewrapper .messagebox").text(message);
}

Demo

For a closer look check out the live demo or download the VS2010 solution from GitHub.

Paul Stovell wrote a very interesting post about choosing when to use HTML, Silverlight or WPF. In the comments, I noticed something that keeps coming back: WPF/Silverlight devs bashing HTML/Javascript as inferior and vice versa.

I’ve heard these discussions a lot and in most cases, people’s preferences are based on the technology that they are most proficient in and not based on facts. The only fact here is that it’s awkward to leave your comfort zone and learn something that is totally different conceptually (stateful vs. stateless).

So when you ask a developer which presentation technology to choose, you should also weigh his background.

Warning: highly subjective content ahead.

In the recent weeks we’ve seen several control vendors come up with toolkits that target ASP.NET MVC. Personally, I don’t see anything that might make me starting to consider picking one of these toolkits to speed up development. Why on earth would I prefer a wrapper around jQuery UI or shoehorning existing WebForms controls in MVC views?

The beauty of ASP.NET MVC is that it embraces the web as it is and this automatically involves HTML, CSS and Javascript. Don’t be afraid for that. The combination can be so powerful! Why aren’t there any large component vendors for PHP, Rails, Django etc? Isn’t it probably possible that these components are not required to do proper web development?

The control vendors seem to be targeting people who come from a Windows background that don’t want to learn HTML and Javascript, but from my experiences I can say that those people should really stick to WebForms.

I’m sure everybody who builds web applications uses grids to display data. There is nothing wrong with that per se, but you might not realize that you’re increasing the customers expectations to an unreachable level:

Yes, all very nice and well, but can’t you make that thing work like Excel?

My first thought is always something like: “sure, if you supply us with the budget that the Excel team has”, but in practice we’ll always end up buying one of those bloated grid components or hacking our own solution where the customers is never 100% happy (because it still doesn’t work like Excel).

The solution?

Don’t format the data in a grid, but in a nicely formatted list and stay away from anything that resembles column headers. Add some simple search and filter options and people are happy.

For a long time, there has been a distinct separation between ASP.NET and PHP developers. The platforms have been so fundamentally different and also have the surrounding cultures. Generally speaking, ASP.NET developers consider the PHP guys script kiddies with no real understanding of ‘real’ software development and the PHP guys saw ASP.NET developers as some M$ infected bunch of people that have no clue of web standards, clean HTML or how to build a proper web app at all.

But times have changed. Both platforms are moving. PHP now has a whole bunch of application frameworks (Zend, CakePHP etc.) that encourage good application design and also since PHP 5, the programming language has improved a lot. On the other hand, with the release of ASP.NET MVC, it has become much more easy to render clean HTML and we can finally leverage all the cool client-side toolkits that are out there without having to work around the quirks of Web Forms. 

So, with this movement, we see that both platforms grow towards each other. More and more developers come to have a look over the fence to see what’s happening at the neighbours place.

Two concrete examples:

• I’m consulting a little at a PHP shop that is moving towards .NET. They found Visual Studio and C# very cool, but the Web Forms issues regarding clean HTML etc. made it an absolute no-go. ASP.NET MVC is what made them switch.
• Just watched the ASP.NET MVC Mix 09 presentation of Rob Conery (Microsoft) and he showed lots of things that were clearly inspired by how PHP apps like WordPress work.

I like this movement! As a .NET developer, I find it very refreshing and inspiring to mix and mingle with ‘the other side’. There is a lot we can learn from each other to make better web applications.