Yesterday it crashed (sigh) and when I rebooted the check disk was triggered. To my, not pleasant, surprise, Check Disk hanged at 1 sec left on the countdown for pressing a key to skip the disk check. Doing a hard reboot several times I was able to start windows again.

Well, after some googling I found the HOTFIX KB 975778 that solved the issue like a charm for me.

@pedroreys nice post on the formatter. I would consider http headers instead of routing, although that is hard to manually debug

The right way to specify the types which are accepted for the response is by using the Accept request-header. It’s been a while since Eric’s tweet, but here is the solution I came up with.

Lemme first define the expectations I defined:

If the Accept header of the request

- Contains “text/html” a ViewResult should be returned.

- Contains “application/json” and not contains “text/html” a JsonResult should be returned

- Contains “text/xml” and not contains “text/html” a XmlResult should be returned

If the requested content type can not be handled by none of the previous statements, a response with a HTTP Status Code 406 – Not Acceptable should be returned.

For this post. I will start with the same controller class that I used in the previous one:

public class ClientController : Controller
    {
        public ActionResult Index()
        {
            var clients = new[] {
            new Client {FirstName = "John", LastName = "Smith"},
            new Client {FirstName = "Dave", LastName = "Boo"},
            new Client {FirstName = "Garry", LastName = "Foo"}
                               };

            return View(clients);
        }

    }

    public class Client
    {
        public string FirstName{get;set;}

        public string LastName{get; set; }

    }

In order to be able to format the result based on the requested content-type on the HTTP header, I will create a base controller class that will provide this functionality to the controller. I will call it ContentTypeAwareController.

public class ContentTypeAwareController : Controller
{
   public virtual IContentTypeHandlerRepository HandlerRepository { get; set; } 

    protected ActionResult ResultWith(object model)
        {
            var handler = HandlerRepository.GetHandlerFor(HttpContext);
            return handler.ResultWith(model);
        }
    }

That’s it. This base class is responsible just to ask the Handler Repository for the right handler to the given HttpContext and call the ResultWith() method on the returned handler.

The IContentTypeHandler interface is pretty simple as well:

public interface IContentTypeHandler
{
    bool CanHandle(HttpContextBase context);
    ActionResult ResultWith(object model);
}

Simple and intuitive, right?

Let’s implement this interface then, but first let’s set the expectations as unit tests:

[TestFixture]
    public class JsonHandlerTest : HandlerTestBase
    {
        [Test]
        public void should_return_a_JsonResult()
        {
            var handler = new JsonHandler();
            var result = handler.ResultWith("whatever");
            result.ShouldBeType<JsonResult>();
        } 

        [Test]
        public void should_Handle_request_when_content_type_requested_contains_Json()
        {
            Headers.Add("Accept", "application/json"); 

            var handler = new JsonHandler();
            handler.CanHandle(HttpContext).ShouldBeTrue();
        } 

        [Test]
        public void should_not_handle_request_when_content_type_requested_does_not_contain_json()
        {
            Headers.Add("Accept", "text/xml"); 

            var handler = new JsonHandler();
            handler.CanHandle(HttpContext).ShouldBeFalse();
        }
    }

To keep the post short, I will put here just the test above, all the other tests are in the solution on github.

The implementation of the JsonHandler is below:

public class JsonHandler : IContentTypeHandler
    {
        public const string _acceptedType = "application/json";
        public bool CanHandle(HttpContextBase context)
        {
            var acceptHeader = context.Request.Headers.Get("Accept"); 

            return acceptHeader.Contains(_acceptedType);
        } 

        public ActionResult ResultWith(object model)
        {
            return new JsonResult
                       {
                           Data = model,
                           ContentEncoding = null,
                        JsonRequestBehavior = JsonRequestBehavior.AllowGet
                       };
        }

It’s important to set the value for the JsonRequestBehavior property on the JsonResult object. Otherwise you will end-up with a InvalidOperationException.

The other handlers are pretty straight-forward as well.

The one to handle requests for Xml:

public class XmlHandler : IContentTypeHandler
{
    public const string _acceptedType = "text/xml";

    public bool CanHandle(HttpContextBase context)
    {
        var acceptHeader = context.Request.Headers.Get("Accept");

        return acceptHeader.Contains(_acceptedType);
    }

    public ActionResult ResultWith(object model)
    {
        return new XmlResult(model);
    }
}

And the other to be the default, Html handler:

public class HtmlHandler : IContentTypeHandler
{
    public const string _acceptedType = "text/html";

    public bool CanHandle(HttpContextBase context)
    {
        var acceptHeader = context.Request.Headers.Get("Accept");

        return acceptHeader.Contains(_acceptedType);

    }

    public ActionResult ResultWith(object model)
    {
        return new ViewResult
                   {
                       ViewData = new ViewDataDictionary(model),
                   };
    }
}

And finally, we will have a handler to return the 406 code in case of the others handlers not being able to handle the requested content type.

public class NotAcceptedContentTypeHandler : IContentTypeHandler
{
    public bool CanHandle(HttpContextBase context)
    {
        return true;
    }

    public ActionResult ResultWith(object model)
    {
        return new NotAcceptedContentTypeResult();
    }
}

With all that code in place, all we have left to do is to make the ClientController to inherit from the ContentTypeAwareController and call the ResultWith() method:

public class ClientController : ContentTypeAwareController
{
    public ActionResult Index()
    {
        var clients = new[]{
            new Client {FirstName = "John", LastName = "Smith"},
            new Client {FirstName = "Dave", LastName = "Boo"},
            new Client {FirstName = "Garry", LastName = "Foo"}
                           };

            return ResultWith(clients);
        }

    }

That’s it. The Client Controller now is able to respond to Json, Xml or Html requests. Let’s check it.

The web page is still being rendered as expected. Fine.

But now, let’s see what responses do I get when I change the Http Header to “application/json”:

Yeah,  a Json result. Cool. What about “text/xml”:

Yeap, that works too. Finally, let’s see if the 406 status code is returned when an invalid content type is requested:

So, with not so much code the Client Controller now is able to format its result based on the Content Type requested on the HTTP Header, as it should have been before. Off course this is a spike and the code can be improved. Feel free to grab it from github and improve it.

In Rails is possible to handle the format that will be returned by the controller as in the following example:

class PeopleController < ApplicationController

def index 

@people = People.find(:all)

respond_to do |format|

format.html

format.json(render :json => @people.to_json)

format.xml(render :xml => @people.to_xml)

end

end

With the controller above, if  one requests the url /people/index the result will be in html. but, if people/index.json is requested instead, the result will be a json file.

That’s a great feature when one is developing an API and let the client code to decide the format it wants to receive the data. Unfortunately, we can’t do that out of the box with ASP.NET MVC. But, ASP.NET MVC gives us lots of extensions points and that allows us to quite easily implement the functionality to mimic this neat behavior.

First, a disclaimer. The solution that I will present is heavily based on the solution present in the routing chapter of the book ASP.NET MVC in Action. The new edition of the book, now covering MVC 2, is, by the time I write this post, in public review. You can get more information about it on this post from Jeffrey Palermo. If you are an ASP.NET developer and don’t have read the book yet, stop everything you are doing and go buy it now.

All that said, lets have some fun.

In our application we have this simple Person entity:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

The application itself is really simple, it just shows a list of People. And yes, I was lazy and used the MVC sample.

I will omit the view code for the sake of brevity as it has nothing to do with the goal of this post.

The PeopleController is pretty dumb too, it just returns a collection of Person to the View:

public class PeopleController : Controller
{
    public ActionResult Index()
    {
        var people = new[]
                {
                    new Person{FirstName = "Joao", LastName = "Silva"},
                    new Person{FirstName = "John", LastName = "Doe"},
                    new Person{FirstName = "Jane", LastName = "Smith"}
                 };
        return View(people);
    }
}

So, it works, pretty straight-forward with default routing. Now, we want to mimic the Rails formatter behavior. So, what we want is that the url /People/Index.json returns a json file instead of the html page. Ok, what we first need to do is check to see if this new url will be routed to the correct Action with the actual route configuration.

With the help of MvcContrib project, we can write the following test to check if our route works as we expect:

[TestFixtureSetUp]
public void Setup()
{
    MvcApplication.RegisterRoutes(RouteTable.Routes);
}

[Test]
public void Should_map_People_url_to_people_with_default_action()
{
    "~/people".Route().ShouldMapTo<PeopleController>(x => x.Index());
}

[Test]
public void Should_map_People_index_json_url_to_people_matching_index_action()
{
    "~/people/index.json".Route().ShouldMapTo<PeopleController>(x => x.Index());
}

As expected, the former test passes, but the latter, the one that tests the new behavior we want to test don’t. And more important, it fails as we expected it to fail.

In order to make it work, we need to add a new route to our Route Dictionary.

routes.MapRoute(
"Format",
"{controller}/{action}.{format}/{id}",
new {id = ""});

With this new route defined, we now get a green test. Neat.

With the route working and the request being routed to the right method, the controller now needs to extract the format information from the route data and handle the output format accordingly.  To achieve this, I’ll create a Layer SuperType, a abstract class that will derive from the base Controller class. The PeopleController, then, will derive from this new class instead of the base Controller one.

This new Controller class, that I will name RailsWannabeController, will override the OnActionExecuting method of the Controller base class in order to extract the requested format from the RouteData. It also will have a property named Format who will store the format information. Finally, it will have a FormatResult method that returns the right ActionResult accordingly to the requested format.

Here is the test to ensure that RailsWannabeController correctly extracts the format information out of the RouteData.

[Test]
public void Should_extract_format_information_from_RouteData()
{
    var expectedFormat = "json";
    var routeData = Stub<RouteData>();
    routeData.Values.Add("format",expectedFormat);

    var filterContext =
        new ActionExecutingContext()
        {
            Controller = Stub<RailsWannabeController>(),
            RouteData = routeData
         };

    var controller = new StubController();
    controller.ActionExecuting(filterContext);
    var requestedFormat = controller.RequestedFormat;
    Assert.AreEqual(expectedFormat,requestedFormat);
}

As the RailsWannabeController will be a abstract class, a MockController StubController concrete class has to be created. This class will derive from RailsWannabeController and will have a public method to enable the OnActionExecuting method to be called. It also will have a RequestedFormat property to expose the value of the requested format extracted from the RouteData.

public class StubController : RailsWannabeController
{
    public string RequestedFormat { get { return base.Format; } }

    public void ActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);
    }
}

Now, all we need to do to make this test pass is code the RailsWannabeController class.

public class RailsWannabeController : Controller
{
    protected static string[]  ValidFormats = new [] {"html","json","xml"};
    protected string Format { get; set; }

    private const string formatKey = "format";

    protected override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);
        ExtractRequestedFormat(filterContext.RouteData.Values);
    }

    private void ExtractRequestedFormat(RouteValueDictionary routeValues)
    {
        if(routeValues.ContainsKey(formatKey))
        {
            var requestedFormat = routeValues[formatKey].ToString().ToLower();
            if(ValidFormats.Contains(requestedFormat))
            {
                Format = requestedFormat;
                return;
            }
        }
        Format = "html";
    }
}

Now that we got a green bar, we have to test if the ActionResult returned by the FormatResult method is from the type requested. That means that if the “json” format is passed in the RouteData, the FomatResult method the object returned must be of type JsonResult.

public void Should_return_the_correct_Action_Result()
{
    var expectedFormat = "json";
    var routeData = Stub<RouteData>();
    routeData.Values.Add("format", expectedFormat);

    var filterContext = new ActionExecutingContext()
    {
        Controller = Stub<RailsWannabeController>(),
        RouteData = routeData
    };

    var controller = new StubController();
    controller.ActionExecuting(filterContext);

    var people = new[]{
                         new Person{FirstName = "Joao", LastName = "Silva"},
                         new Person{FirstName = "John", LastName = "Doe"},
                         new Person{FirstName = "Jane", LastName = "Smith"}
                     };

    var formattedResult = controller.GetFormattedResult(people);
    Assert.AreEqual(typeof(JsonResult),formattedResult.GetType());
}

There is a LOT of code in this test. Much more then I’d like it to have. But to keep the code as explicit as possible, for sake of clarity, I left it that way. I’ll let the refactoring of this code as an exercise for the reader.

As you may guess from the code above, the MockController StubController class had to be modified to include the GetFormattedResult method.

public class StubController : RailsWannabeController
{
    public string RequestedFormat { get { return base.Format; } }

    public void ActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);
    }

    public ActionResult GetFormattedResult(object model)
    {
        return base.FormatResult(model);
    }
}

In the  RailsWannabeController we have to create a FormatResult method that, as it name states, format the result accordingly to the format requested.

protected ActionResult FormatResult(object model)
{
    switch (Format)
    {
        case "html":
            return View(model);
        case "json":
            return Json(model);
        case "xml":
            return new XmlResult(model);
        default:
            throw new FormatException(
                string.Format("The format \"{0}\" is invalid", Format));
    }
}

ASP.NET MVC framework gives us the Json method out of the box. The XmlResult is provided by the MvcContrib project.

Now, all we have to do is change the PeopleController class to derive from the Layer SuperType instead of the Controller base class. And change the View() method call to be a call to the FormatResult method.

public class PeopleController : RailsWannabeController
{
    public ActionResult Index()
    {
        var people = new[]
            {
                new Person{FirstName = "Joao", LastName = "Silva"},
                new Person{FirstName = "John", LastName = "Doe"},
                new Person{FirstName = "Jane", LastName = "Smith"}
             };
        return FormatResult(people);
    }
}

OK, all the tests are green and we are done coding. Let’s check if all we’ve done works properly.

Using the default route we get the same result. Great.

If “json” format is provided in the URL we get a json file instead. Woot.

Finally, requesting a xml we get the result in a XML file. That’s it we are done.

I know the post is a little bit long, but that’s because my intention was to explicit all the process of mimicking the behavior of the Rails formatter. And, as you should do as well, I managed to have the code I was working on to be covered by tests that gave me the confidence that I wasn’t breaking anything while I was making the changes. It is specially important to cover your routes with tests as route changes can introduce some hard to find bugs. I hope this post helps to show that, although ASP.NET MVC may not have all the features we want it to have, it’s high extensibility allows us to extend it and easily introduce new behaviors.

As I’m not a native English speaker, I ask and encourage you to point out not only technical mistakes but also any language related mistakes that I’ve made at this post.

UPDATE: As Giovanni correctly pointed out in his comment, the MockController class is not a Mock but a Stub. I renamed the class to StubController to avoid misunderstandings. Thanks, Giovanni.

That’s what Seth Godin is offering. Quoting him, what he offers is:

Six intense months working with a few other amazing people (and me.)

It is a really awesome opportunity for one who already lives or can afford the expenses of living 6 months in NYC.

It is not everyday that one have has the chance to get 6 months of coaching and learning from someone like Seth, and for free.

Source: Squiido via Scrum4You

This is the first post of my new blog.

Some of you may be familiar with the Portuguese written blog that I co-author with Jorge Maia. At this one I’ll be writing in English only, I hope. :)

Well, as soon as I finish all the WordPress settings, I will start to post here.

For you who don’t know me yet, I suggest reading the “About” section.

Cheers,

Pedro Reys