Los helpers nos van a permitir crear campos para crear un formulario de una manera muy cómoda.
En el artículo anterior vimos el uso de POST en ASP.NET MVC junto con las bases del Model Binding. En concreto la norma más importante que debemos recordad es que el atributo name del campo debe llamarse igual que la propiedad que queremos enlazar. Por supuesto que el Model Binder admite enlazar parámetros complejos (una clase que tenga una propiedad que sea una lista de objetos que a su vez tengan más propiedades simples o complejas) y en este caso basta que los atributos name de los campos del formulario sigan unas determinadas reglas. No vamos a entrar más en detalle porque, por suerte el framework nos ofrece una ayuda para no tener que recordar exactamente todas esas reglas: Los helpers para formularios.
Los helpers nos van a permitir crear campos para crear un formulario de una manera muy cómoda y son sin duda alguna la manera preferida de hacerlo.
Crear campos HTML
Lo primero que vamos a ver es como crear un campo HTML para editar (o mostrar) una propiedad específica del Viewmodel que recibe la vista. Supongamos que tenemos esa clase:
public class Trabajador
{
public string Nombre { get; set; }
public string Apellido { get; set; }
public DateTime FechaNacimiento { get; set; }
public double Sueldo { get; set; }
public bool EsFijo { get; set; }
}
Ahora vamos a crear una vista que muestre cuatro campos de texto (para nombre, apellido, fecha de nacimiento y sueldo) y una casilla de verificación para indicar si es fijo o no. Pero en lugar de crear los controles a mano (<input type="xxx">) vamos a usar los helpers:
Html.TextBoxFor que muestra un campo de texto para la propiedad indicada
Html.CheckBoxFor que muestra una casilla de verificación para la propiedad indicada
Fijaos en como se indica a cada helper para que propiedad debe renderizar el control:
@Html.TextBoxFor(x=>x.Nombre)
El parámetro en forma x=>x.Nombre es una expresión lambda. No es objetivo de este artículo entrar en las expresiones lambda, así que nos vamos a limitar a indicar que en este caso se usan para indicar la propiedad. La ventaja de usar una expresión lambda antes que una cadena (algo como TextBoxFor("Nombre")) es que las expresiones lambda son evaluadas en tiempo de compilación y no de ejecución (si nos equivocamos en el nombre de la propiedad el código no compila). Esto requiere que la vista sea tipada con el tipo de ViewModel (fijaos en el uso de la directiva @model).
Bien, ahora veamos que código fuente nos ha generado esta vista:
La verdad es que no se diferencia mucho del código que nosotros pondríamos a mano (que vimos en el artículo anterior). Lo que sí os puede llamar la curiosidad es el campo hidden cuyo name es "EsFijo". Este campo existe para bueno, para lidiar con el hecho de que una checkbox no marcada, no se envía. Es decir si tenemos el campo:
Eso significa que si la checkbox está marcada se enviará el valor indicado en value (true), mientras que si la checkbox no está marcada el navegador no enviará nada. Una checkbox no marcada es como si no existiese. Pero el Model Binder de ASP.NET MVC esperará que haya un campo EsFijo para poder enlazarlo a la propiedad, de ahí que se añada este campo hidden con el mismo nombre y valor false. De este modo si la checkbox no está marcada el campo hidden se envía y tiene el valor de false. ¿Habrías pensado tú en eso? Esas son las ventajas de usar los helpers :)
Ventajas de usar los helpers
Pero todavía hay más, si mostráis la vista en el navegador y sin introducir datos le dais a Enviar:
¡Exacto! Nos aparecen errores. En concreto el sistema nos muestra un error si FechaNacimiento o Sueldo están vacíos. ¿Y por qué esos dos campos y no los otros? Muy sencillo: porque esos dos campos están declarados como DateTime y double que son tipos por valor y por lo tanto nunca pueden valer null.
Ahora probad de meter una cadena en el Sueldo:
¡Sigue dando error! Esto es porque la cadena dsddsd no puede ser convertida en double, lo que genera un error.
Ahora bien, quiero dejar una cosa bien clara: El sistema siempre realiza esas validaciones con independencia de que usemos los helpers o no. Pero estos últimos están preparados para mostrar el error (usar una clase CSS específica) si ese existe.
Ahora igual os surge la siguiente duda: ¿Y si no uso los helpers como puedo saber si hay errores en un campo concreto? Pues haciendo lo mismo que realmente hacen ellos: Acceder a la propiedad ModelState del ViewData que entre otras cosas contiene los errores vinculados a una propiedad. Mirad como sería el código si queremos generar el campo Sueldo para que se comporte igual que usando el helper:
Tenemos que realizar manualmente las dos tareas que el helper hace por nosotros:
Establecer la propiedad value al valor del ViewModel recibido si lo hubiese
Establecer la clase a input-validation-error en caso de haber un error vinculado en el campo que estamos mostrando.
Así pues, los helpers no son imprescindibles. Pero sí que son muy cómodos y la manera recomendable de construir formularios en ASP.NET MVC.
Hemos visto TextBoxFor y CheckBoxFor pero hay un helper por cada control HTML que habitualmente usamos en formularios, así tenemos Html.TextAreaFor, Html.LabelFor, Html.DropDownListFor, etc
Os muestro el uso de Html.LabelFor porque es otro que se usa muchísimo. Ese genera un campo
Eduard Tomàs
Apasionado de la informática, los videojuegos, rol y... la cerveza. Key Consulta...
