MVC AJAX Support
In the latest preview of the Microsoft ASP.NET MVC Framework, one of the newly included features is AJAX helper methods. It's going to be interesting to see where they go with these. At the moment, they've added just a couple of tasters. This blog post discusses how to set them up and make use of them if you want to try them out. Currently, there are two helper methods that have been created, Ajax.ActionLink and Ajax.Form. I will discuss both below. They both generate HTML, much in the manner of pre-existing helpers such as Html.Form.
The first thing to look at is how to set a page up to be able to make use of these helper methods. Since they are going to call parts of the JavaScript libraries that are part of the Microsoft AJAX Framework, you need to include them in the head section of your page. There are two files that you need to include. Microsoft are currently shipping them in both debug and release configurations. It doesn't matter whether you have debug or release, but you will need to have both files included, and included in the correct order. This will look something like the following:
1: <head runat="server">
2: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
3: <title>AJAX Example</title>
4: <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
5: <script type="text/javascript" src="../../Content/MicrosoftAjax.js"></script>
6: <script type="text/javascript" src="../../Content/MicrosoftMvcAjax.debug.js"></script>
7: </head>
Once these have been included, you will be free to use the AJAX tools that have been developed. It is worth a quick aside to briefly discuss the payload size of these Framework helpers. Currently, MicrosoftAjax.js represents about 89KB and MicrosoftMvcAjax.debug.js is about 6KB. These numbers obviously aren't too bad. They're bigger than the equivalent jQuery files, and it will be interesting to see how it matches up as time goes on.
Having set up the Framework requirements, we can proceed to use the tools supplied. The essence of the helpers that have been created so far is that they allow you to easily make an asynchronous call to a Action Method and to use the response. This essentially makes it possible to create the equivalent of the UpdatePanel from WebForms. This is probably best now illustrated with a simple example, building on top of the standard MVC site that is shipped with the Framework. In the code for the Index view (Index.aspx), we can include something like the following:
1: <div id="testContainer">
2: <%= Ajax.ActionLink("About", "About", new AjaxOptions { UpdateTargetId = "testContainer" })%>
3: </div>
The next stage is to alter the About view (About.aspx) to remove most of the strapping from it. It is not going to need to have a MasterPage for example, or in fact to have anything but some example text.
So, what is the effect of all this? Well, run it up in a browser and we'll see what happens. As you might expect, running the default page for the site brings up the Home/Index page as normal. Some way down the page, there is a link with the text 'About'. So we click on it. What should happen, all being well, is that the contents of the About view becomes inserted into the page in place of the About link.
Obviously, there is fairly limited potential in links for passing information back to the controller, so the natural extension is to want to have an 'AJAXified' form. And lo and behold, one exists. Ajax.Form works in a very similar manner to Html.Form (with the exception of needing AjaxOptions just like ActionLink does). And indeed it 'just works' much like you would expect.
One final aspect of this Framework is worth discussing in this post I believe, and that is controlling what view is selected. Obviously if we have received a request as an AJAX request into the controller it is highly likely that we will want to show a different view to if we had received it as a normal HTTP request. In this case, there is a helper method that is your friend:
1: if (Request.IsMvcAjaxRequest())
2: { 3: }This does exactly what it says on the tin and will tell you from where a request originated. The most obvious use of this is, as mentioned above, in switch which view to use. The fact that a view can be an ascx file just as easily as an aspx file gives us therefore a fairly neat way of providing a page with something that will feel a lot like an UpdatePanel in the centre. Instead of the UpdatePanel, we can make the part of the page that will update an ascx file and then include it as a UserControl in our normal view page. We therefore serve the aspx page the first time (when the request is a normal HTTP request) and can then serve just the ascx file for subsequent MVC AJAX requests.
I do feel at the moment that this framework offers only fairly coarse grained control compared with what is currently available through something like jQuery. The word on the street (or at least ScottGu's blog) is that they're making this a pluggable part of the process just like every other part of MVC. Certainly for ActionLinks at the moment, I think jQuery represents a better solution (lighter, more flexible and just as powerful). For Ajax.Form, I'm not sure one way or the other yet, but it does look like a relatively neat solution. You can certainly achieve the same functionality using jQuery and cause a form to POST, but it does require a certain amount of duplication of code between the jQuery code and the HTML code to set up the form.