Category Archives: Web development

MvcPaging 1.0.2

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

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.

 Screenshot

The sample application can be found at GitHub.

Keep your users informed with ASP.NET MVC

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

success

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;
                }
            }
        }
    }
}

x-message

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.

Developers are afraid to choose a different presentation technology

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.

Considering ASP.NET MVC UI controls? Learn HTML and Javascript!

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.

The problem of data grids in your web application

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.