mvc

ASP.NET MVC: Tricky modelbinding feature (?)

Erik van Brakel — Wed, 25 Nov 2009 23:24:58 GMT

I just ran into a situation which could lead to very annoying latent bugs in your web application. Observe the following code.

The view:

<form method="post" action="Photo/Save">
  <input type="text" name="Photo" />
  <input type="text" name="Title" />
</form>

The Controller action:

public ActionResult Save(PhotoDTO photo)
{
    // do something with the object
    return RedirectToAction("Index");
}

The class:

public class PhotoDTO
{
    public string Photo { get; set; }
    public string Title { get; set; }
}

At first sight, there’s nothing wrong with this code. You’d say when the form is posted, the PhotoDTO object gets automatically created by the default modelbinder in the framework, and you’ll be able to do what you want with the PhotoDTO (like, errr, save it?). However, what REALLY happens is that the parameter photo will be null. Now I’ll give you a moment to realize what’s happening.

…

Alright, that’s enough. What’s happening is that the field with the name ‘Photo’ is getting precedence over binding the whole thing to the PhotoDTO class. So let’s say I put the value “SomePhoto” in the textbox, it’ll try to bind that value to an object of the type PhotoDTO. That fails, so it returns null.

I’m not sure it’s intended, I’m assuming it’s just a side-effect of what needs to be done to be able to bind to complex models as well as simple parameters. Either way, if you’re not aware of this quirk you’re in for a surprise if you accidentally run into this!

The conclusion

I asked Phil Haack on twitter if this was intended. He said:

@erikvanbrakel yes, by design. BTW, your PHotoDTO needs to make properties public too.

So there you have it, keep this in mind when writing your code, it’s not going anywhere, it’s as intended!

Note: I corrected the PhotoDTO, it was missing the ‘public’ access specifiers.

ASP.NET MVC: Access an action only by ajax

Erik van Brakel — Mon, 05 Oct 2009 10:00:00 GMT

In a standard ‘web 2.0’ (god, I hate that buzzword) web application, you’ll often have ajax calls to your code. I prefer using jQuery, but any method will do. A proper ajax request will set a header value in the HTTP GET request, and ASP.NET is a good boy and catches that. By checking if the IsAjaxRequest() method on the request returns true.

This feature can be utilized for something I like to do on my ajax-exclusive controller actions: restrict access in such a way that only ajax requests can call the action. Other actions will get a 404, which effectively means the action will never be indexed by search engine crawlers, for one. To do this, I think a good way is to follow the convention set by the framework itself on restricting the actions to certain verbs (GET, POST): use an attribute on the method!

So how do we do this? It’s very simple actually. ASP.NET MVC provides a bunch of extension points, and this is one of them. There’s an class in the framework called ‘ActionMethodSelectorAttribute’, which contains only one method, which returns true if the call is permitted, false if it isn’t. On each call to an action, the framework checks for any attributes on the method which implement this class, and makes sure all of these return true. Simply put: we’ll implement the class in such a way that it will return true when the action is called via ajax:

public class AjaxRequestAttribute : ActionMethodSelectorAttribute
{
    public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo)
    {
        return controllerContext.HttpContext.Request.IsAjaxRequest();
    }
}

I told you it was simple. Now you can use this attribute in your controllers, as such:

public class HomeController : Controller
{
    [AjaxRequest]
    public ActionResult Index()
    {
        return View();
    }
}

Yes, this is a silly example. It demonstrates the functionality though. When you go to /Home via your web browser now, you will get a 404, page does not exist. However, when you call /Home via ajax, you’ll get the HTML output from the view returned. That’s it.

ASP.NET MVC: Common viewdata

Erik van Brakel — Thu, 01 Oct 2009 23:50:53 GMT

One issue I’ve heard a few times already when explaining ASP.NET MVC to others is how to deal with common viewdata which should be available to every page. Sure, you can simply add it to the viewdata in each and every controller action you call, but that’s a horrible violation of the DRY (Don’t Repeat Yourself) principle. It’s also very error-prone, because you’re very likely to forget to add it some time or another.

A more elegant solution to the problem is to have a base controller class which you will use for all your controllers. This is a no-brainer, really, as there’s almost always a case which warrants this solution.

A more elegant solution indeed!

The default Controller class used in ASP.NET MVC offers some interesting hooks for changing the behavior of your application. The ones we’re interested specifically are the event hooks, methods called ‘On…()’. In this case, we’ll make use of the OnActionExecuting() method. This method is called right before an action is executed. What we’re going to do is add a few things to the viewdata collection, so we can guarantee this data to be available at every point in the application.

First, let’s create a base class with the method mentioned overriden:

using System.Web.Mvc;

namespace CommonViewDataSample.Controllers
{
    public abstract class ControllerBase : Controller
    {
        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            ViewData["MyViewData"] = "Something common here!!!";
            base.OnActionExecuting(filterContext);
        }
    }
}

Take note of setting the data in viewdata collection, which will now be available in any view you request.

Now, going by the sample ASP.NET MVC project that’s generated whenever you create a new MVC project, we’ll adapt the controllers in that project to make use of this base class:

In Controllers/HomeController.cs

public class HomeController

becomes

public class HomeController : ControllerBase

In Controllers/AccountController.cs

public class AccountController

becomes

public class AccountController : ControllerBase

Now you're set! In ANY view, masterpage, partial view or whatever, you can now use ViewData["MyViewData"] just like you'd use any other viewdata. There are more ways to reach this goal, but this is the simplest form other than putting your viewdata in every controller action, so I figured I’d touch this first. I will write about other methods do this later, so stay tuned!