Dec 16

The MVC platform – the HtmlHelper class (part II)

Posted in ASP.NET MVC      Comments Off on The MVC platform – the HtmlHelper class (part II)

Today we’re going to keep talking about the methods associated with the HtmlHelper classes. In this post, we’ll concentrate on the extension methods defined on the InputExtensions.cs file that allow us to introduce several textboxes on a page (ie, HTML Input elements if you really want to  be picky). We’ll end up analyzing the three overloads of the TextBox method:

public string TextBox(string name)
public string TextBox(string name, object value)
public string TextBox(this string name, object value, object htmlAttributes)
public string TextBox(string name, object value, IDictionary<string, object> htmlAttributes)

The first overload lets you specify the name/id of the control. You can use that overload when you don’t want to explicitly specify the value of the textbox. The remaining overloads will let you set the value and attribute pairs you can define on the INPUT control (do notice that you can use the anonymous method approach or the dictionary approach).

The easiest way to use these helpers is illustrated on the next snippet (dropped on the aspx page):

<%= Html.TextBox( "name" ) %>

The previous line is responsible for injecting the following HTML on the page shown on the browser:

<input  id="name" name="name" type="text"  />

Lets suppose that you want to set the class to a predefined CSS style called myInput. Here’s one way of doing that:

          Html.TextBox( "name", //name/id of the textbo
                              null, //value shown
                              new { @class = "myInput"} ) //other attributes


with the corresponding HTML:

<input class="myInput" id="name" name="name" type="text"  />

If you wanted, you could also use the overload which receives a dictionary (for this short illustration,using the anonymous object was more than enough,right?). As you can see, we didn’t pass anything to the value attribute. Nothing prevented us from passing a value to it, but it’s important to keep in mind that if you do that, you’ll loose the “automatic filling behavior”. “Auto what?” you’re asking? well, never mind the name. It’s just something I invented to explain what happens when you have an element whose key is the same as the id of a textbox and that doesn’t have an explicit value set.

To illustrate this approach, lets suppose that we have a simple form:

<form method="post" action="">
  <%= Html.TextBox( "name”) %>
  <input type="submit" id="myBt" value="Try to submit" />

It’s just a simple textbox and a submit button which will only refresh the current form  (ie, it will start a new request to the current url which will then instantiate the controller and will call the right method to handle the request and return a response back to the client). Yes,there are some helpers for generating forms too but we’ll leave that for future posts…

Now, if you have something like this in your controller’s method that handles the request and “calls” the view that had the previous snippet:

ViewData["name"] = Request.Form["name"];

You’ll always end up initializing the control with the last value that the user entered before submitting the form. Yes, you don’t need to do anything else (besides calling the TextBox method from the aspx page and passing it the same id as the key of the item that was passed into the view data dictionary). Interestingly, this behaviour will also work when you have strongly typed view. For instance, if you had a class that looked like this:

public class Data    {
        public String name { get; set; }

and the previous TextBox method call (<%= Html.TextBox( "name”) %>) then you could expect the textbox to have the value of the name property of that class with the following code:

return View( new Data{name = "Hooo"});

In other words, the value of the input HTML control will always be set to Hooo.

Do notice that this behaviour is slightly modified when you use validation. If you add a “model state” to your form and associate it with a control, then that value will always “overwrite” the other values you try to pass to the control. We’ll talk about simple validation on the next post (ie, we’ll interrupt the HtmlHelper analysis for introducing the validation classes introduced by ASP.NET MVC).

And that’s all for today. Keep tuned!