Ok, not really! It’s still free…today I didn’t really had the time to dig into the stuff I wanted to investigate. So, I’ll just present several interesting topics about the MVC futures assembly:
- Binders: the MVC future has some offers in this area. Let’s start with the ByteArrayModelBinder. This binder will recover a byte array from an existing field (as you might expect, it will try to interpret the value as a base 64 string). Before using this binder, don’t forget to register it with the ModelBinders.Binders collection. There’s also a SkipBindingAttribute which you can use to skip binding on an action controller’s parameter;
- Extensions: besides the extensions we’ve seen in the previous posts, there are a couple of other extensions which might be useful to you. Let’s start with the MailToExtensions. As you might expect from the name, these HtmlHelper method extensions let you add mailto links to your web views. There are several overloads which let you specify mail, subject, cc, bcc and body for the message. The ExpressionInputExtensions class adds several helpers which let you add textboxes, hidden fields, dropdowns,textareas and validation messages to a view. The main difference when compared to the ones present on the main MVC assembly is that these methods use Expressions for specifying the association between the generated field and a model property. If you’re looking for radio button helpers,then you’ll be pleased to know that the futures assembly has several helpers that might help you with that. RadioListExtensions is the class you want for this job. Items that are to be rendered should be passed through a collection of SelectListItem;
- Caching: the futures assembly introduces a class (CacheExtensions) which lets you specify a method that should be called for rendering portions of the page that shouldn’t be cached. Internally, you’ll end up using the WriteSubstitution method of the HttpResponseBase class (which, in practice, means that you’ll end up calling that method over the HttpResponse class).
Since we still haven’t talked about using caching on MVC apps, I though this would be a good time for presenting a small example which illustrates the use to the CacheExtensions’ static methods. Lets suppose we’ve got a view which is cached. However, there’s a section which shouldn’t be cached, ie, there’s a specific portion of the view that should be regenerated for all the requests. Here’s how you might do that with this extension method (I’m just putting the view):
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
<%@ OutputCache VaryByParam="None" Duration="60" %>
<%@ Import Namespace="MVCRTM.Controllers"%>
<%@ Import Namespace="Microsoft.Web.Mvc"%>
<asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent" runat="server">
<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">
<%= Html.SubmitButton( "Message", "hi" ) %>
<%= DateTime.Now %>
<% Html.Substitute( ctx => DateTime.Now.ToString() );%>
Ok, this is just a really simple (and dumb!) view with a form whose sole objective is to force a refresh of the view. Without caching, you should see both times being refreshed. However, after adding the cache directive, you should notice that only the second date will be updated. Notice that the Substitute method expects a MvcSubsitutionCallback delegate, which looks like this:
public delegate string MvcSubstitutionCallback(HttpContextBase httpContext);
As you can see, you cam access the current context from within the method you’re passing to handle the substitution.
And that’s all for today. Keep tuned for more on the MVC framework.