Some Considerations For MVC 6 Client Attributes

One of the new features coming is the addition of Tag Helpers, which are server-side attributes that get interpreted and translated into a client-side attributes. This transforms the previous approach we used to use of the following:

@Html.ActionLink("Text", "Action", "Controller")
@* OR *@
<a href="@Url.Action("Action", "Controller")">Text</a>

Both of the above examples translate to the same result; Html.ActionLink builds a link with a single HREF attribute. One of the changes available with tag helpers is to instead use new “asp” prefixed attributes to perform the rendering:

<a asp-controller="Controller" asp-action="Action">Text</a>

These attributes get translated to a href client-side attribute with the appropriately generated URL. There are a variety of tags available that support server-side attributes, outside of the hyperlink. For instance, the form and label tags also support attributes, as well as others that you can find more at the following resources:

There is lots of good content out there on the subject already. I wanted to discuss in this post the merits of tag helpers, and discuss some of the pros and cons. Whatever is discussed with tag helpers, it’s important to remember that you can always utilize the old way of developing the user interface. To my knowledge, that isn’t going away.

It is important to remember that tag helpers are server-side; they still run server-side code, and so you cannot use asp attributes at client time. The client-side interpreters do not know of these attributes, but the server does as in this post. So if you like to use jQuery or Kendo UI templating, tag helpers won’t really give you much, as you have to render the link anyway. Now, there are server-side tricks to rendering client content that can be utilized, which I have written about in the past on this blog, and so there are ways to leverage that depending on what you are doing.

You also have to be careful which attributes you use where, as certain attributes are supported for certain tags. I haven’t found a comprehensive list yet, other than the Mikesdotnetting post. So be careful as you use new attributes to account for that. Also, some properties define expressions to the field in the model that may contain additional information. For instance, the label may support a field to grab the display information. In this case, the attribute defines the name of the field to display information for, which corresponds to the property in the model. It will be interesting to see how Tag Helpers support deep nested models, and whether we need to render names like Customers[0].FirstName when working with lists. This is one area where the old tags make it a little more clear.

These are some preliminary ideas to think about; I’m sure I’ll be amending this post as I think of other considerations after publishing this post 🙂

ASP.NET MVC Seamless Routing Encryption

There are certain pages in the application where the data passed in must be encrypted in a GET request. This could be a link redirection from an email or another site, or just an internal redirect where the parameters can’t get exposed. A link like this may actually look like:

/Some/Action?enc=345SFIPOWHG:LNNJE:LKJWET46-DSFSF:KJ

The data is nonsensical to the user, but contains identifying information about the user. For instance, the encrypted data may have the following information:

– User ID
– Response Identifier
– Response (Yes/No, Agree/Disagree, text description, whatever else)

The system can then check that the user logged in matches the user in the URL request. It can lookup the associated response database record, and record the response provided. This feature is not native to ASP.NET MVC, but is relative easy to build in. This post will illustrate how to do so, using the following steps:

1) The first step is to create an action method to define a URL. We’ll want to create two forms: one method as a redirection, and one method as an URL generation. Both of these will be extension methods on different objects:

private static string GetEncryptedData(object args)
{
    var encryption = new EncryptionService();
    var list = new RouteValueDictionary(args);
    var items = new List();

    foreach (var entry in list)
    {
         items.Add(entry.Key + "=" + (!string.IsNullOrEmpty(entry.Value) ? entry.Value : ""));
    }

    return encryption.Encrypt(String.Join("&", items));
}

public static ActionResult RedirectToActionSecure(this ControllerBase controller,
                                                  string action, 
                                                  string controller, 
                                                  object args)
{
    var encText = GetEncryptedData(args);
    return controller.RedirectToAction(action, controller, new { enc = encText });
}

public static IHtmlString ActionSecure(this UrlHelper url, 
                                       string action, 
                                       string controller, 
                                       object args)
{
    var encText = GetEncryptedData(args);
    return url.Action(action, controller, new { enc = encText });
}

Certainly, you can create overloads without the action and/or controller too, which is easy to do. Additionally, this code should do more null checking; it assumes that the data exists. The first step is get a reference to the encryption service you are using for your application. I’m leaving that out of this post. Using this service, a querystring is generated and then encrypted together. The value is stored in the “enc” querystring value when routed. This looks like in the code:

public ActionResult X()
{
   return RedirectToActionSecure("Action", "ctlr", new { a = 1, b = 2 });
}

Or in the view:

@Url.ActionSecure("Action", "ctlr", new { a = 1, b = 2 });

When a request is made to that controller and action, MVC checks for the “enc” querystring parameter. It does this in an Action filter attribute, on ActionExecuting.

public class EncryptionActionAttribute : ActionFilterAttribute
{
   public override void OnActionExecuting(ActionExecutingContext context)
   {
        var encryption = new EncryptionService();

       // Step 1: parse the URL
       var url = context.HttpContext.Request.Url.ToString();
       var index = url.IndexOf("enc=");

       if (index > 0) {
         //Get the encrypted value and decrypt it.
         var encText = context.HttpContext.Server.Decode(url.Substring(index + 4));
         var groups = encryption.Decrypt(encText).Split('&');
         var actionParams = filterContext.ActionDescriptor.GetParameters();

         //Parse all of the "KEY=VALUE" groups
         foreach (var group in groups)
         {
            var pair = group.Split('=');

               if (pair.Value == null)
                 continue;

               //Make sure the action has the parameter of the given name
               var actionParam = actionParams.FirstOrDefault(i => i.Name == pair.Key);
               if (actionParam != null) {
                  var nullType = Nullable.GetUnderlyingType(actionParam.ParameterType);

                  //If a nullable type, make sure to use changetype for that type instead; 
                  //nullable types are not supported
                  if (nullType != null)
                     context.ActionParameters[pair.Key] = 
                          Convert.ChangeType(pair.Value, nullType);
                  //Otherwise, assign and cast the value accordingly
                  else
                     context.ActionParameters[pair.Key] = 
                          Convert.ChangeType(pair.Value, actionParam.ParameterType);

               }

         }
       }
   }
}

There’s a lot to it, so let’s break it down:

– Again, missing null checks and conversion error recovery, so you’ll want to ensure that’s there.
– The first step is to grab the encrypted value from the URL and decode it; once we have this value, the encrypted value is decrypted to get the key/value pairs.
– The filter context has two parameter types: ActionDescription, which GetParameters() returns the metadata of the action method, and ActionParameters, which is a collection of values about to be injected into the action. The ActionParameters collection can be added or modified as you like.
– Each key/value pair is evaluated, and injected into the ActionParameters collection; the values that were encrypted were injected in.
– We first have to check that a nullable type is converted correctly; otherwise, the cast to a nullable type through ChangeType raises an exception.

Some/Action?enc=23442q5wetew

It’s decrypted to:

UserID: 1
ResponseID: 3
Response: YES

The values are inserted into an action method like this:

Customizing the MVC Form

MVC has a set of wrappers for generating forms, which is illustrated using the following in C# Razor:

using Html.BeginForm()
{
  @* Form content *@
}

Under the scenes, Html.BeginForm renders a tag for the current controller/action (or custom ones if the parameters are supplied). It does more than that though; it works with a FormContext and generates a unique ID for the form. Being that the Microsoft way is to internalize a lot of their components, it makes it difficult to customize.

It’s actually pretty easy to customize the MVC form using a wrapper. There are several good reasons for doing so. The first reason is standardization. Most forms provide some common header or footer content around their forms to improve the appearance, or to follow a specific CSS framework. The form could also output a ValidationSummary at the top, thus saving the developers from having to write it. I did this similarly with the Anti-forgery tokens so that every form was protected.

The first step to doing so is create a form class:

public class CustomForm : MVCForm
{
    private MvcForm _form = null;
    private ViewContext _viewContext = null;
    private bool _disposed = false;

    public CustomForm(MvcForm form, ViewContext viewContext) : base(viewContext)
    {
       _form = form;
       _viewContext = viewContext;
    }
}

The constructor of the form wraps the MVC form, taking it as the first constructor parameter, and the ViewContext which the form expects. To render the end of the form, override the Dispose method, and do the following:

protected override void Dispose(bool disposing)
{
    if (_disposed)
      return;

     //Wrap up any customization HTML here

     if (_form != null) {
       _form.Dispose();
     }
    _disposed = true;
}

On disposing of the form, this renders the end of the form (the end tag, and wrap up some of the internal form stuff).

The initial rendering of the form happens in the BeginForm extension method, so we need something similar:

[Extension]
public static CustomForm BeginCustomForm(this HtmlHelper html, ..)
{
   var form = html.BeginForm(..); //set parameters to form, let the original form do the work or rendering
   html.ViewContext.Writer.Write(html.AntiForgeryToken());
   html.ViewContext.Writer.Write("I'm within the form, write any customization text here");
}

Here the html.BeginForm extension renders the tag with any attributes provided. It also writes the anti-forgery token and a custom message.

And that’s all it takes to standardize your applications forms and minimize the actual amount of code you have to write! It can amount to a time savings over the long run of an application.

Custom ASP.NET MVC Helper Extensions

As you probably are aware of, ASP.NET MVC was a divergence from the approach developers took to developing ASP.NET web forms applications. For web forms developers, any level of customizations occurred by creating custom ASP.NET server controls, inheriting from a particular base class and adding some functionality, something like:

public class SuperLabel : Label
{
   // Enhanced functionality
}

There are many benefits to doing this; you can initialize the control’s properties for your web application, or encapsulate repeatable code into a common class that’s reused throughout the application. For instance, if we know that we will always render our form labels in a specific manner, I could create a custom control to do this following:

public class FormLabel : WebControl
{

   protected override void Render(HtmlTextWriter writer)
    {
         writer.Write("<div>" + this.Text + "</div>");
    }

}

And that way, every label is wrapped in a div with a FormLabel class. This is a simple example of standarizing your control’s output and thus your client’s markup, but you get the idea. This is also possible in ASP.NET MVC, with the help of your own helper methods.

Note that there are two kinds of helper methods in MVC: ones who return an MvcHtmlString object and render the text inline, and ones that render inside the method and are defined as @Html.DoSomething(); (with a semi-colon at the end; in VB this method can be called in a @Code block). I’m going to talk about helpers that return an MvcHtmlString in this blog post. As a simple example of a helper we may want to standardize on, we can, for instance, wrap a DIV with a special class around the Html.EditorFor helper as in the following example:

public static class HtmlHelperExtensions
{

  public static MvcHtmlString CustomEditorFor(this HtmlHelper html, Expression<Func> expr)
  {
     return new MvcHtmlString("<div>" + html.EditorFor(expr) + "</div>");
  }

}

As you can see, we have a custom editor with a wrapper DIV around it now, which we can put in our UI by doing:

@Html.CustomEditorFor(i => i.ModelProperty)

The TModel and TProp generic references above are inferred from the current view’s model, and the property expressed in the lambda expression. If you look in other MVC helpers, they are all defined with these two generic references. The HtmlHelper class has a lot of useful features; first it has access to all the extension methods as you would use them in the UI (most defined in the System.Web.Mvc.Html namespace, but there are additional namespaces too). It also has a reference to the ViewContext and to the current model for the given view, via the HtmlHelper.ViewData.Model property (remember HtmlHelper is specific to the model, therefore it maintains an explicit, strongly-typed reference to said model).

I’ve only scratched the surface, but you can see a lot of options are available to you. For instance, if you use Twitter bootstrap, maybe you want your editor helper to look like:

 public static MvcHtmlString CustomEditorFor(this HtmlHelper html, Expression<Func> expr)
  {

     return new MvcHtmlString(
  @"<div class=\"control-group\">" + 
    html.LabelFor(
        expr, 
        new { @class = "col-md-2 control-label" }
     ).ToHtmlString() +
   @"</div>
     <div class=\"col-md-10\">" + 
    html.EditorFor(expr) + 
    "</div>");

  }

And thus, this saves you from writing a lot of HTML. In the future, I may write on some of the extensions I’ve used for twitter bootstrap to save time. I hope this is a good overview of how you can customize HTML helpers in ASP.NET MVC, which I am using this technique in a current ASP.NET MVC 5 application.

Using JSON in Facebook C# API without the need for dynamic

If you happen to look at a lot of the examples that the Facebook C# API uses, you’ll notice a some of examples utilize the dynamic keyword (another example). This makes sense because it’s supported by the C# language and is a very nice feature to use.

In case you didn’t know, dynamic defers any type checking until runtime; this means that you can dynamically refer to a type, without intellisense in the Visual Studio designer, only to be met with type checking at runtime. If you call a property or method that doesn’t exist on an object reference, for instance, an exception will be thrown at runtime, but the code will still compile.

Recently, I’ve been using Xamarin Android and iOS frameworks for developing mobile applications, and I stumbled upon a limitation: dynamic is not supported, which this code broke when I tried to port it from Android to iOS:

var attributes = fb.Get<IDictionary<string, object>>("/me?fields=id,name,first_name,last_name,picture");
.
.

if (attributes.ContainsKey ("picture"))
{
   dynamic pictureObj = attributes["picture"];
   if (pictureObj != null) {
      dynamic data = pictureObj ["data"];

      if (data != null)
         pictureUrl = data ["url"].ToString ();
   }
}

The facebook API returns the current user’s picture as a complex object, that is represented by the following:

picture: { data: { url: "urltoimage" } }

That’s not all that comes along, but is mostly what we care about for this discussion. Anyway, to parse it using dynamic created a problem in iOS, as this generated errors. The solution was to use the following instead:

if (attributes.ContainsKey ("picture"))
{
   var pictureObj = attributes["picture"] as Facebook.JsonObject;
   if (pictureObj != null) {
      var data = pictureObj ["data"] as Facebook.JsonObject;

      if (data != null)
         pictureUrl = data ["url"].ToString ();
   }
}

The Facebook C# team does not want you using JsonObject directly, which is why it doesn’t show up in intellisense, but it is supported, and is the only representation of an object that allows you to easily extract the URL from the picture object, without a lot of reflection. This then works seamlessly in both Android and iOS.