Modelo

Una clase ViewModel con los parámetros de la búsqueda y con una lista de resultados.

public class BuscarViewModel
{
    public string Texto { get; set; }
    public bool EnMayusculas { get; set; }
    public IEnumerable<dynamic> Resultados { get; set; }
}

Controlador

Una acción Buscar de tipo GET que recibe los parámetros de la búsqueda. Por simplicidad, uso el mismo ViewModel como parámetro de entrada, para aprovechar el trabajo del ModelBinder de MVC. La acción rellena el valor de Resultados, en teoría considerando los parámetros de búsqueda, aunque en este caso he usado valores de ejemplo.

Imaginemos también una peculiar regla de negocio que nos exige que la casilla “Coincidir mayúsculas” se devuelva siempre desmarcada, incluso si ha sido marcada en la búsqueda anterior. Para ello, en el modelo recibido la establecemos a falso.

public ActionResult Buscar(BuscarViewModel buscarViewModel)
{
    buscarViewModel.EnMayusculas = false;                         //Siempre se pone a falso
    var ejemplo = new {Texto = "Ejemplo" };
    buscarViewModel.Resultados = Enumerable.Repeat(ejemplo, 50);  //Ficticio
    return View(buscarViewModel);

}

Esta acción responde a las siguientes URI (suponiendo un controlador EntidadController):

• /Entidad/Buscar
• /Entidad/Buscar?Texto=abc&EnMayusculas=true

Vista

Una vista muy sencilla podría ser:

@model MvcCheckBoxForFail.Models.BuscarViewModel
@{
    ViewBag.Title = "Buscar";
    var grid = new WebGrid(Model.Resultados);
}

<h2>Búsqueda</h2>
@using (Html.BeginForm("Buscar", "Entidad", FormMethod.Get)) {
    <fieldset>
        <legend>Buscar @Model.Texto en mayúsculas @Model.EnMayusculas</legend>

        <div>
            Texto
            @Html.EditorFor(model => model.Texto)
            Mayúsculas
            @Html.EditorFor(model => model.EnMayusculas)
            <input type="submit" value="Buscar" />
        </div>

        @grid.GetHtml()

    </fieldset>
}

Sus elementos principales son:

• Un WebGrid nativo de MVC para mostrar los resultados con una sencilla paginación en servidor.
• Un Form con método GET.
• Los campos para el texto y para forzar la coincidencia de mayúsculas, generados ambos con EditorFor.

Problemática

Si probamos esta sencilla página, nos encontraremos con un curioso comportamiento: no sigue la regla de que la casilla de forzar mayúsculas debe salir siempre desactivada. Por el contrario, mantiene el valor usado para la búsqueda. Pero nosotros hemos asignado false claramente en el controlador, por lo que ¿quién es el responsable de que se muestre la casilla activada? A este nivel, el culpable es el método EditorFor, que no usa el valor que trae el modelo (sí, de ahí el resaltado amarillo, soy muy malo para mantener el suspense). Más adelante depuraremos mejor las responsabilidades.

Antes de eso, probamos con otras opciones. Por ejemplo, en lugar de EditorFor, usaremos CheckBoxFor:

@Html.CheckBoxFor(model => model.EnMayusculas)

El comportamiento, como era de esperar, es idéntico. Así que vamos un paso más allá y usamos el método CheckBox:

@Html.CheckBox("EnMayusculas", Model.EnMayusculas)

Para nuestra sorpresa, el comportamiento sigue siendo el mismo, aún cuando Model.EnMayusculas es siempre falso. Pero es más, si escribimos:

@Html.CheckBox("EnMayusculas", false)

Incluso indicando el valor de false explícitamente, el input se renderiza marcado (checked) en ciertas ocasiones. ¿Cómo es esto posible?

Primera explicación

En primer lugar, ya hemos identificado en qué casos se activa la casilla: cuando estaba marcada al hacer la búsqueda, es decir, cuando se recibe en la QueryString un EnMayusculas=true.

NOTA: En la QueryString se recibirá siempre un EnMayusculas=false, independientemente de que se marque o no la casilla. Esto es debido al hidden que genera CheckBoxFor. Para más información sobre este comportamiento, ver esta respuesta de Jeremy.

¿Qué se deduce de aquí? Pues que al usar los métodos del helper Html para renderizar un control (no sucede sólo con el CheckBox, probadlo con otros), si el nombre indicado existe en la QueryString recibida, se usará ese valor independientemente de su valor en el modelo o del valor estricto que le pasemos al helper. Hay más información sobre este comportamiento en esta incidencia respondida por RanjiniM de forma contundente: “Este es el comportamiento esperado en ASP.NET MVC”.

Soluciones

Ante esto, pueden buscarse distintas soluciones. Yo voy a plantear las dos más extremas.

La primera es dejar de usar el helper CheckBox e insertar un input en HTML directamente. Incluso podemos elaborar nuestro propio helper que evite este comportamiento.

Pero antes veamos la segunda solución, que es la que propone RanjiniM en la respuesta anterior: excluir la propiedad en cuestión del uso del ModelBinder. La firma de la acción incluirá un nuevo atributo, quedando así en nuestro controlador:

public ActionResult Buscar([Bind(Exclude="EnMayusculas")] BuscarViewModel buscarViewModel)

El atributo se aplica al parámetro, no al método completo, y define la propiedad (o propiedades, separadas por comas) para las que queremos evitar el comportamiento descrito. Una vez establecido este atributo, el código original (usando CheckBoxFor) funciona correctamente, y la casilla sale desmarcada en todos los casos.

ModelBinder y ValueProvider

Con la ayuda de Luis Ruiz Pavón y de Eduard Tomàs he revisado cómo puede afectar el orden de definición de los ValueProvider a esta incidencia, pero mis pobres conocimientos no me han permitido llegar a una conclusión.

Yo entiendo que tanto el ModelBinder como los ValueProvider se utilizan a la hora de generar el modelo, es decir, de construir la instancia que se pasa como argumento a la acción Buscar. Pero una vez generada esa instancia de BuscarViewModel, no consigo entender por qué vuelve a prevalecer el valor de QueryString sobre lo que pone en el modelo. Si los valores de QueryString ya se han trasladado al modelo, lo lógico después es trabajar con el modelo, que puede haber sufrido cambios como en nuestro supuesto.

La intención de toda esta exposición es doble: en primer lugar, servir de ayuda a quien pueda encontrarse esta misma incidencia; y por otro lado, tratar de comprender mejor la justificación de este comportamiento, que según afirma RanjiniM no es un bug sino el comportamiento esperado (a no ser que estemos disfrazando un bug de feature como tantas veces Por eso agradezco vuestros comentarios y opiniones al respecto.

Un placer.

• Iniciar sesión automáticamente con un usuario y contraseña dados (suponiendo, como en mi proyecto, que se prohíbe por requisito que el navegador recuerde al usuario).
• Rellenar valores de mi conveniencia en un formulario.

Como estas cosas, aunque las implemente, no quiero que ni por lo más remoto puedan llegar a producción, uso la constante de compilación DEBUG que indica si estamos ejecutando en Debug o en Release (y si tenemos más configuraciones, podremos indicar si la queremos declarar o no). Como mi código en producción irá como Release, no corro el riesgo de ejecutar mis atajos para depuración.

En un proyecto web MVC, según dónde nos encontremos, la forma de detectar si estamos en Debug o Release es distinta como vamos a ver a continuación.

Directivas de precompilación y DEBUG

Las directivas de precompilación de C# permiten que el compilador considere un código u otro en función de unas constantes, como DEBUG en nuestro caso. Por ejemplo, algo como:

#if DEBUG
        string username = "pablo";
#else
        string username = null;
#endif

Hace que los programas generados en Debug y en Release sean distintos: uno llevará una asignación a “pablo” y el otro a null. Ojo que no existe doble declaración de la variable: en un caso se declarará una y el propio compilador ignorará la otra línea, no sólo no se ejecuta, es que ni se compila.

Usando estas directivas no corro el riesgo de olvidarme de quitar este código de depuración cuando genere mi versión para producción: se usará el código que asigna null.

Un código similar he usado en mi MembershipProvider (no pongo el ejemplo porque mi caso es muy particular y dependiente de un motor de bases de datos muy particular) para iniciar una sesión concreta siempre en Debug, mientras que en Release el usuario debe iniciar sesión.

Las directivas de precompilación tienen más usos, como usar un mismo código base para diferentes targets, como Silverlight, Windows Phone… con algo como:

#if SILVERLIGHT

Lo cual nos acerca a aquello de un código, tres pantallas. Aunque no es el tema de hoy.

Detectando modo Debug en Razor

Pensando bien, uno interpreta que esto se puede aplicar al código C# incrustado en Razor. Yo he intentado usarlo para el segundo punto planteado al inicio de este artículo, y de forma natural uno piensa que puede hacer:

@{
#if DEBUG
        string titulo = "pablo";
#else
        string titulo = null;
#endif
}

Cuidado, esto no funciona. Y tiene sentido que no lo haga: este código dentro de Razor no es compilado al publicar el proyecto, sino que es incrustado en las vistas, y luego las vistas son compiladas por IIS según necesidad. Por lo que #if DEBUG siempre devuelve true. No sirve.

Pero hay otra forma de detectar que estamos en Debug desde Razor, y aunque no es exactamente igual, en la mayoría de los casos será equivalente y nos servirá. Se trata de la propiedad:

Context.IsDebuggingEnabled

Que nos ofrecen las páginas Razor a través de su HttpContext. De esta forma sí podemos hacer:

@{
    string titulo;
    if(Context.IsDebuggingEnabled)
        titulo = "pablo";
    else
        titulo = null;
}

Con lo que podemos usar esa variable @titulo como valor del elemento input correspondiente para que al cargar la página tengamos un valor inicial. Ojo, esto se podría (debería) hacer en el modelo (viewmodel) usado en la página, pero entonces podríamos usar directivas de precompilación y no tendría gracia el uso de IsDebuggingEnabled, así que he forzado un poco el ejemplo para mostrar este caso.

Conclusión

Podemos hacer trucos en nuestro código que nos faciliten la tarea rutinaria de ejecutar una y otra vez una aplicación en desarrollo para llegar a la página que estamos implementando, saltando los pasos que un usuario debería recorrer. Esta simplificación puede aumentar considerablemente nuestra productividad, pero cuando lo hagamos, debemos seguir los cauces que existen para ello (detección de DEBUG con #if, propiedad IsDebuggingEnabled) para que al pasar la aplicación a producción no quede ni rastro de nuestros trucos. Y ojito también con lo que subimos al control de código fuente, a ver si otro compañero se va a encontrar con nuestros atajos y quizá no le vayan a hacer mucha gracia.

Un placer.

Code Contracts

Code Contracts es un proyecto de Microsoft Research para incluir en nuestro código las precondiciones y poscondiciones que deben cumplirse antes y después de su ejecución, así como los invariantes que deben cumplirse siempre. Muchos no habrán usado estas palabrejas desde que dejaron la Universidad, otros ni eso, pero al programar todos estamos asumiendo premisas que deben cumplirse (por ejemplo, que un método debe llamarse antes que otro, o que una variable tenga un rango de valores concreto), sólo que no los reflejamos en ningún sitio, sólo están en nuestra cabeza. Ahí es donde interviene Code Contracts, permitiendo poner negro sobre blanco (pixel negro sobre pixel blanco, quiero decir) esas condiciones, y además verificando que se cumplan tanto durante la ejecución de nuestro programa como de nuestros tests.

Como idea es muy interesante, y permite incrementar la calidad de nuestro código, difuminando un poco la división entre programa y tests, ya que estas comprobaciones (equivalentes a los Assert de un test) están en el propio programa. También ayuda a la legibilidad del código y a su comprensión por parte de quien venga detrás (que normalmente somos nosotros mismos dentro de un tiempo). Y su uso no es nada difícil, como muestra un botón:

public void Bind(FrameworkElement bindingObject, Func<FrameworkElement, FrameworkElement> bindingObjectParentFunc)
{
    Contract.Requires<ArgumentNullException>(bindingObject != null, "Binding object cannot be null.");
    Contract.Requires<ArgumentNullException>(bindingObjectParentFunc != null, "Binding object function cannot be null.");
…

En lugar de comprobar si nos han pasado bien los atributos con un if, lo estamos declarando usando Contract, el punto de acceso principal a la librería Code Contracts. Se entiende fácil, ¿verdad? Pues si queréis saber más, os dejo aquí una presentación de un chico que parece que sabe de esto.

¿Pero qué te ha pasado hoy?

Pues nada, que estaba tratando de localizar un error en la versión que estamos preparando para WPF de SilverDiagram, y entre cambios de código y recompilaciones de librerías me he encontrado con este error:

El texto es bastante más extenso, pero qué os voy a contar de esas hermosas pilas de llamadas listadas en enormes MessageBox. Todo un símbolo, y perfecto para demostrar a nuestro jefe/usuarios lo difícil que es nuestra profesión.

La cuestión es que este error viene provocado por Code Contract, porque se da una situación curiosa: Tengo dos librerías, A y B. La librería B referencia a A (pero están en soluciones distintas, así que referencia el ensamblado A.dll, pongamos).

Yo estaba probando B sin problemas, tratando de corregir el error, haciendo cambios y pruebas normalmente. Cuando identifico que el error parece estar en A, abro su solución, lo corrijo y compilo para usar esta nueva A.dll. Esta compilación no se queja.

Compilo B con la nueva A.dll y de nuevo sin problema. Pero al ejecutar, el error, ah, el error: Must use the rewriter when using Contract.Requires<TException>.

Está claro que la culpa es de Code Contracts. Echo una búsqueda rápida, y encuentro en el blog de Derik Whittacker una coincidencia. Y hace especial hincapié en que la culpa no es de B, sino del proyecto A, a pesar de no haber dado errores en su compilación. Y el motivo es sencillo: no tengo instalado Code Contracts en mi ordenador.

Instalando… y solucionado

Así que tras cerrar los Visuales Estudios, descargo e instalo desde la web de Code Contracts (hay versión comercial y académica, pero no me preguntéis sobre eso). Una vez instalado, conseguimos dos cosas:

1. En las Propiedades de los proyectos hay una nueva pestaña Code Contracts donde podemos definir el comportamiento de esta librería en nuestro proyecto.
2. Al volver a compilar el proyecto, ya podemos usar A.dll con normalidad en otros proyectos (si estaba bien configurada la comprobación en tiempo de ejecución de las propiedades de Code Contracts, pero esto es harina de otro costal).

Espero que esto pueda servir de ayuda para quienes sufran el mismo problema, y también para que algunos nos empecemos a introducir en Code Contracts (…por mi primero).

Un placer.

Aunque yo suelo trabajar con EF aplicando la metodología Code-First, de nuevo por simplicidad decido plantear la demo como Model-First, por aquello del interfaz gráfico y demás (que está sobrevalorado, donde se ponga un buen interfaz de código fluido…). Bueno, creo un archivo .edmx y defino en él 2 tablas con su propio Id autonumérico como clave primaria y una clave foránea entre ambas. Cuando pido Crear base de datos a partir del modelo en el menú contextual, me pide crear una conexión a base de datos, y me ofrece 3 proveedores: SQL Server, archivo mdf y Sql CE 3.5.

Decido continuar con mi idea de usar CE aunque sea 3.5 (ya veré después… sólo estoy preparando una demo). Creo un nuevo archivo sdf para la conexión y Visual Studio me genera un archivo edmx.sqlce con el script de base de datos para generar las tablas. Lo conecto al sdf y ejecuto sin problemas. Pero al incluir código para crear una entidad y ejecutarlo, obtengo el error:

Server-generated keys and server-generated values are not supported by SQL Server Compact.

Lo cual no es del todo cierto, bueno, casi lo era cuando se escribió ese mensaje de error, ya que Sql CE 3.5 no soporta autonuméricos generados en el servidor a través de Entity Framework, es decir, realmente es una carencia del provider y no del motor. Con esto, Sql CE 3.5 no me sirve para mi sencillo ejemplo, donde no voy a montar ningún generador de claves. Esta carencia ha sido subsanada en Sql CE 4.0, así que doy marcha atrás y me lanzo a la búsqueda de esta versión.

Hasta ahora, cuando lo había necesitado (para Code-First y para Elmah) había usado el paquete nuget. Pero esto no sirve para EDMX, ya que debe estar registrado el proveedor en Visual Studio. De ahí que me descargo las SQL CE Tools for Visual Studio SP1 (que ya lo tenía) desde este artículo de ScottGu (no sé si también estará en español, he buscado un poco y no lo he encontrado). Pero tras instalarlo, me siguen saliendo los mismos proveedores que antes, por lo que investigo un poco y descubro que el proveedor Sql CE 4.0 sólo se ofrece en el EDMX dentro de proyectos web, no en mi humilde proyecto de consola. De hecho si en un proyecto web creo el sdf de la versión 4.0 y añado una conexión a él en el Explorador de servidores de Visual Studio, al tratar de usarlo desde el EDMX no se incluye en el combo (sólo se incluyen las conexiones con Sql CE 3.5 o con Sql Server). Es realmente desagradable ver cómo un EDMX añadido a una librería de clases (que es lo aconsejable, extraer el modelo fuera del proyecto web) sólo permite usar Sql CE 3.5 mientras que en un EDMX dentro de un proyecto web sí se ofrece Sql CE 4.0:

Todo esto me parece una situación extraña y limitadora, ya que Sql CE 4.0 es una solución ideal para pequeñas aplicaciones o utilidades, o para la primera fase de algunas aplicaciones mayores, incluso para instalaciones pequeñas de esas mismas aplicaciones; y con esta carencia se dificulta su utilización práctica para quienes prefieren usar el EDMX en lugar de la aproximación Code-First. Sólo me queda añadir que esta restricción puede salvarse siguiendo este truco (en inglés), que implica modificar el EDMX a mano, y que puede servir a los más tenaces (los demás habrán desistido antes, tristemente).

Y para terminar tengo que dar las gracias a mis agazapados del Twitter, Marc Rubiño y Rodrigo Corral, por echarme una mano y compartir experiencias acerca de Sql CE (incluso siendo el día del Señor). Es un gustazo tener a gente así leyendo mis tonterías para ayudar. Otra vez gracias.

Un placer.

http://mi.com/Form/Show?url=http://geeks.ms

http://mi.com/Form/Show?name=Geeks

Es decir, para quien usa la página, nuestra acción Show puede recibir una URL o bien el nombre de una página que ya tengamos previamente guardada. Son las dos formas de acceder al servicio. Por poner algo más de contexto, puede imaginar el lector un servicio como Google Mobilizer (transformar una página para facilitar su lectura en dispositivos móviles) mezclado con un gestor de marcadores (bookmarks). El uso de la misma ruta en ambos casos es una decisión de diseño que no depende de nosotros.

Este diseño admite dos posibles planteamientos en MVC:

• Una única acción con dos parámetros opcionales, url y name.
  • Según el parámetro dado, elegir un comportamiento u otro.
  • Decidir qué hacer si nos pasan los dos parámetros (por ejemplo, dar un error).
• Dos acciones separadas, una con un parámetro url y otra con name.
  • Pro: podemos organizar mejor nuestro código (en cada acción lo suyo).
  • Pro: la decisión la hace MVC, no necesitamos discriminar según los parámetros recibidos. Queda más natural.
  • Contra: no es soportado de forma nativa en MVC 3, como veremos.

Como el código de ambas acciones no tiene apenas nada en común, me gustaba más la segunda opción, por lo que vamos a ver si podemos ir salvando los obstáculos que nos encontremos en el desarrollo del ejemplo. Para comenzar:

1. Creamos un nuevo proyecto ASP.NET MVC 3 de nombre SelectingActionByArgumentsName.
2. Usamos la plantilla Vacía (Empty) y motor de vistas Razor (View engine).
3. Añadimos un nuevo controlador: clic derecho en la carpeta Controllers, y elegimos Agregar (Add) > Controller.
4. Le llamamos FormController, y lo creamos vacío (Empty controller).

Ya tenemos el proyecto listo para incluir nuestras dos acciones. Bajo la acción Index que se genera siempre, añadimos las dos nuestras, devolviendo sólo un contenido (para simplificar):

public ActionResult Show(string url)
{
    return Content("Loaded from url");
}

public ActionResult Show(string name)
{
    return Content("Loaded from name");
}

Y encontramos el primer obstáculo:

C# no admite dos métodos con la misma firma en una clase.

Evidentemente, aunque el nombre de los parámetros sea distinto, son del mismo tipo, por lo que C# (no ASP.NET MVC, sino el compilador) nos dará un error. Contra esto, poco podemos hacer, hay que cambiar algo. Pero existe una solución sencilla: añadir un parámetro opcional. Esto hará que los métodos sean diferentes. Por ejemplo, vamos a añadir un parámetro opcional save a la acción que recibe una url:

http://mi.com/Form/Show?url=http://geeks.ms&saveAs=Geeks

Este parámetro indica que queremos que se guarde la dirección con ese nombre. De hecho, hemos aprovechado para añadir funcionalidad, pero en la práctica podríamos haber añadido un parámetro sin utilidad y no usarlo nunca (su única utilidad sería permitir que el compilador acepte nuestros dos métodos de forma válida). Y lo haremos opcional, por lo que la URL inicial seguirá funcionando. Así que cambiamos la primera acción por:

public ActionResult Show(string url, string saveAs = "")

Y ya tenemos el primer obstáculo salvado: el compilador no se queja. Ya podemos ejecutar. Pero si navegamos a (en xxx irá el puerto de vuestro servidor web):

http://localhost:xxx/Form/Show?name=Geeks

Recibimos un error ahora de ASP.NET MVC (segundo obstáculo):

The current request for action ‘Show’ on controller type ‘FormController’ is ambiguous between the following action methods:
System.Web.Mvc.ActionResult Show(System.String, System.String) on type SelectingActionByArgumentsName.Controllers.FormController
System.Web.Mvc.ActionResult Show(System.String) on type SelectingActionByArgumentsName.Controllers.FormController

ASP.NET MVC no sabe elegir qué acción utilizar. ¿Pero no hemos puesto name en nuestra URL? Pues usa la acción que tiene un argumento name, so tonto (no sé si vosotros también soléis insultar a la pantalla). Pero no: ASP.NET MVC no usa los nombres de los argumentos para elegir qué acción llamar durante el proceso de enrutado (por defecto, que como casi todo en MVC 3, esto puede cambiarse). Ojo, sí usa los nombres después para asignar los parámetros, pero eso es cuando ya ha elegido la acción; es para elegirla cuando no los considera. Sólo sus tipos. Y usando sólo los tipos, se encuentra con esa ambigüedad.

Pero como hemos dicho, casi todo en MVC 3 puede cambiarse, y además de diferentes formas. En este caso, vamos a usar una solución vista en StackOverflow, aunque modificada para hacerla más genérica, dirigida a cambiar el mecanismo de selección de acciones (sí, ese que hemos dicho que se basa en los tipos) para que considere también los nombres de los argumentos. Y además vamos a hacerlo mediante un atributo para que sólo afecte a las acciones donde lo necesitemos. Para esto, sólo debemos crear una clase que extienda de ActionMethodSelectorAttribute y sobreescribir el método IsValidForRequest, que es quien realizará la comprobación.

public class SelectByArgumentNamesAttribute : ActionMethodSelectorAttribute {
    public override bool IsValidForRequest(ControllerContext controllerContext,
                                           MethodInfo methodInfo) {
        return methodInfo.GetParameters()
                .All(pi => pi.IsOptional
                        || controllerContext.HttpContext.Request[pi.Name] != null);
    }
}

Un detalle aclaratorio: no tenemos que comprobar el nombre del método, ya que esto lo hace ASP.NET MVC antes de llamar a esta validación. Sólo tenemos que comprobar si, según los datos de la petición (Request), este método (methodInfo) es el apropiado o no. Por lo que comprobamos que todos los argumentos del método vienen en la Request (con su nombre), salvo que sean opcionales.

Ahora sólo tenemos que usar este atributo en las acciones conflictivas (en ambas). Por ejemplo:

[SelectByArgumentNames]
public ActionResult Show(string url, string saveAs = "") {
…

Tras usar el atributo en las dos acciones, ya podemos probar a navegar a las URL:

http://localhost:xxx/Form/Show?url=http://geeks.ms

http://localhost:xxx/Form/Show?name=Geeks

¿Pero qué sucede? Que todavía nos queda por salvar el tercer obstáculo, aunque no está relacionado con lo anterior. Si comprobáis, veréis que funciona correctamente con la primera dirección (con o sin el parámetro opcional) pero falla con la segunda, la que usa el parámetro name.

¿Por qué? Bueno, pues este es uno de esos problemas que nos invitan a creer en la magia y abandonar la programación para dedicarnos a echar las cartas, hasta que descubrimos de qué se trata: la culpa es del nombre elegido para el parámetro url, dado que siempre que preguntemos por Request[“url”] obtendremos un valor, nunca es null, aunque no hayamos pasado ningún parámetro con ese nombre en la URL, porque el valor obtenido es ¡el de la propia URL de la petición!

Por suerte, este obstáculo es el de más fácil solución: en lugar de buscar en Request, profundizamos un poco más hasta Request.QueryString, donde sólo están los parámetros que vienen en la QueryString, con lo que sólo habrá un url si se lo pasamos, y si no devolverá null. La solución pasa por cambiar:

controllerContext.HttpContext.Request[pi.Name] != null

por

controllerContext.HttpContext.Request.QueryString[pi.Name] != null

Y resuelto. He querido incluir este último obstáculo por 1. ser fiel a la realidad (recordad que el artículo está basado en hechos reales) y 2. por la moraleja, parafraseando: “el más mínimo desconocimiento de la herramienta puede hacerse pasar por magia”.

En conclusión, hemos visto cómo se puede cambiar de forma muy sencilla la forma en que ASP.NET MVC selecciona la acción a partir de la URL. Recordad que, igualmente, muchos otros comportamientos generales se pueden modificar y adaptar a los casos concretos, o incluso esto podíamos haberlo conseguido de otras formas. Y sobre todo, lo más importante: hay que conocer bien la herramienta con la que trabajamos para adaptarla, entenderla… y distinguirla de la magia.

Un placer.

public class InformeController : Controller
{
    //
    // GET: /Informe/Ventas?desde=6/1/2011&hasta=6/30/2011&centros=1,2,3

    public ActionResult Ventas(DateTime desde, DateTime hasta, int[] centros)
    {
        return Content("Centros: " + string.Join(" / ", centros));
    }
}

Para mi informe necesito un rango de fechas definido por desde y hasta, y una lista de centros definidos por sus Id. El paso de parámetros en la URL, mediante HTTP GET, tiene para mí muchas ventajas, entre ellas la facilidad para realizar pruebas.

A modo de test devuelvo una cadena con los centros separados por barras, para que se vea que no hay truco. En el comentario del propio código puede verse cómo sería una llamada, el interés está en el parámetro centros que recibe una lista separada por comas de los Id (dejando de lado que las fechas deben ir en inglés, pero esa es otra cuestión). La elección de la coma como separador es mía, aunque sigue una convención bastante extendida.

La cuestión es que esta acción tan sencilla e intuitiva no funciona puesto que en el argumento centros no se recibe el valor deseado en todos los casos.

• En el ejemplo del comentario, con centros=1,2,3 en la QueryString, recibiremos null en centros. Mal.
• En cambio, si pasamos centros=1 recibiremos un array con un entero de valor 1. Bien.

¿A qué se debe esto? Bien, tenemos que saber que estamos confiando en el ModelBinder de ASP.NET MVC para convertir los valores de la QueryString (nuestra URL) en los parámetros de nuestras acciones. Este ModelBinder tiene una funcionalidad muy completa con los tipos sencillos, pero poco más. Si necesitamos algo extra, como es nuestro caso, no nos ayuda.

Pero ASP.NET MVC tiene múltiples puntos de extensión, entre ellos la posibilidad de definir nuestros propios ModelBinder para cubrir los tipos que necesitemos. Así que vamos a definir uno para permitir la recepción de un array de enteros en un formato separado por comas. Sólo tenemos que extender de IModelBinder:

public class ArrayOfIntModelBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        return controllerContext.HttpContext.Request[bindingContext.ModelName]
            .Split(',')
            .Select(int.Parse)
            .ToArray();
    }
}

Esta interfaz sólo nos exige implementar el método BindModel que tiene la responsabilidad de transformar el trozo de la QueryString donde va nuestro parámetro (y que es un string, no lo olvidemos) en el valor destino, en nuestro caso un array de enteros. Recibe dos argumentos:

• El contexto del controlador, que incluye la información de la petición (Request). De aquí obtenemos el valor del parámetro en la QueryString.
• El contexto del modelo, en nuestro caso el argumento destino de la conversión. De aquí obtenemos el nombre del argumento buscado, que en nuestro ejemplo anterior sería “centros” pero que si usamos bindingContext.ModelName tenemos un Binder genérico que nos sirve para cualquier otro uso de array de enteros en otra acción (o incluso como otro parámetro en la misma).

El resto del método es sencillo: dividimos la lista de enteros usando la coma como separador, los convertimos a enteros con int.Parse y convertimos el IEnumerable resultante en un array. Pido perdón por mi concisión en el código, parte de la culpa la tiene Linq, otra buena parte Resharper, y otra yo mismo, qué pasa, si tenemos un lenguaje potente y hermoso como C# es para aprovecharlo, ¿no?

Bueno, nos queda la parte más importante, porque como ya imagináis esta clase por sí misma no hace nada si no le decimos a ASP.NET MVC que la utilice al procesar las peticiones. Para esto, basta con incluir en el Global.asax.cs una línea como:

ModelBinders.Binders[typeof(int[])] = new ArrayOfIntModelBinder();

Podemos ponerla en Application_Start(), y su mandato es sencillo de definir con palabras: “cuando encuentres un parámetro de tipo array de entero, lo procesas con esta instancia y no con el ModelBinder genérico.” Dicho y hecho, si todavía tenéis la URL anterior, volved a ejecutar el proyecto y refrescar esa página, podéis comprobar como ahora el parámetro centros devuelve todos los enteros que hayamos tenido a bien suministrarle en la URL.

Un placer.

En esta página podemos encontrar:

• Enlace a los ejemplos y extensiones alojados en codeplex.
• Videotutoriales del canal de Youtube de Silverdiagram:
  • Como construir los ejemplos alojados en Codeplex (en inglés).
  • Como crear formas personalizadas (en inglés).
• Enlaces a la documentación.
• Próximamente, recopilación de artículos, posts…

Seguid atentos a los nuevos videos y ejemplos. Esperamos que todo este material sea de ayuda a quienes queráis conocer más sobre SilverDiagram.

1. Convertir el proyecto a .net 4.0 (necesario)
   Basta con cambiarlo en propiedades del proyecto, pero no os olvidéis de confirmar con vuestro hosting que soporta el framework 4 (yo no tengo problemas porque los chicos de Domitienda-Businet están siempre a la última).
   NOTA: Cuidado porque al cambiar el framework se pierde la sección <configSections> del web.config, hay que volver a introducirla, como se indica aquí. Puedes recuperarla comparando diferencias con la versión anterior del control de código fuente que uses (y si no lo usas, sigue cavando tu tumba).
2. Añadir assemblies en Web.config / compilation. Algunas de las librerías que indica Eduard ya estarán, puesto que Dynamic Data ya las incluye. En mi caso sólo he tenido que añadir:

   <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
   <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
   <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

3. Incluir espacios de nombres de MVC para las páginas, en Web.config / system.web / configuration / pages
   

   <pages>
     <namespaces>
       <add namespace="System.Web.Helpers" />
       <add namespace="System.Web.Mvc" />
       <add namespace="System.Web.Mvc.Ajax" />
       <add namespace="System.Web.Mvc.Html" />
       <add namespace="System.Web.Routing" />
       <add namespace="System.Web.WebPages"/>
     </namespaces>
   </pages>

   
   

4. Agregar referencias a System.Web.Mvc.dll (normalmente desde C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies). Si vas a usar Razor (¡cómo no!) también System.Web.WebPages.dll (desde C:\Program Files\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies).
5. Inicializar MVC en el Global.asax.cs
   Uso el mismo código de Eduard, pero ojo porque Dynamic Data ya genera un método RegisterRoutes, así que renombramos el nuestro por RegisterRoutesMvc (también su uso en MvcInit).

   private void MvcInit()
   {
       AreaRegistration.RegisterAllAreas();
       RegisterGlobalFilters(GlobalFilters.Filters);
       RegisterRoutesMvc(RouteTable.Routes);
   }
   
   public static void RegisterGlobalFilters(GlobalFilterCollection filters)
   {
       filters.Add(new HandleErrorAttribute());
   }
   
   public static void RegisterRoutesMvc(RouteCollection routes)
   {
       routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
       routes.MapRoute("Default", "{controller}/{action}/{id}",
           new {action = "index", id = UrlParameter.Optional});
   }

6. Cambiar el tipo de proyecto (para que Visual Studio nos ofrezca las herramientas de MVC, como Add controller, Go to view y demás comandos).
   Hay que añadir {E53F8FEA-EAE0-44A6-8774-FFD645390401} en <ProjectTypeGuids> del .csproj (ya sabes, Unload project y después Edit .csproj). Ojo que ese Guid debe ser el primero, los dos que ya estaban deben seguir pero detrás de este (así viene en un nuevo proyecto de MVC, puedes consultarlo si tienes dudas).
7. Añadir manualmente la estructura de carpetas de MVC: Controllers, Views y Shared con las plantillas _ViewStart.cshtml, Layout.cshtml y el Web.config de Razor (sí, fíjate que en los proyectos de MVC tienes un Web.config dentro de Views; pues cópialo en tu carpeta Views y listo). Y bueno, ya estás en MVC, el resto ya es cosa tuya, ¿no? Si quieres echa un vistazo a cómo puedes empezar.

Dynamic Data es una herramienta potente para elaborar prototipos, poner en marcha rápidamente proyectos, y para ofrecer un mantenimiento sencillo de tablas (CRUD) a usuarios finales. Pero cuando la aplicación comienza a crecer, toda la ayuda que ha prestado en la fase inicial se convierte en obstáculos, por lo que es una buena idea ir abandonándolo, al menos para las páginas que tengan cierta lógica de negocio. Y es esa la oportunidad para ir migrando a MVC, ya que se va a llevar muy bien con Dynamic Data, se permite incluso tener rutas parcialmente comunes entre ambos: por ejemplo, yo tengo Acciones/List.aspx de Dynamic Data y Acciones/Notificar atendida por un Controller de MVC.

Por cierto, comentar que hace un tiempo oí que el equipo de Dynamic Data estaba planteando su migración a MVC (todavía su base es el ASP.net clásico, ya que Dynamic Data es anterior a MVC). En ese caso la integración con MVC resultará mucho más natural. Pero con las novedades de MVC que han llegado y que se esperan, quizá dicha evolución no llegue nunca a ver la luz, ya que MVC ofrece una gran facilidad para el desarrollo rápido de aplicaciones y prototipos.

Lo que sigue no es un tutorial sino una recopilación de enlaces (pocos), consejos y opiniones para comenzar con ASP.net MVC. Y está escrito de forma informal porque con mi amigo tengo mucha confianza

1. Ya está la versión 3.0, olvídate de las anteriores (y ten cuidado al seguir artículos o tutoriales, ha habido una evolución importante desde las anteriores: ojo a la fecha de los artículos).
2. Además de instalar VS2010 y su SP1, debes instalar las MVC 3 Tools Update.
   Pero para no tener que hacer todo esto, en http://www.asp.net/mvc hay un botón Install Visual Studio Express que te lo hace todo. Y con la versión Express tienes suficiente para empezar… y para terminar la aplicación.
3. Apúntate a AUGES (http://www.auges.org/), un grupo online centrado en ASP.NET.
4. Su primer evento fue Un paseo por ASP.NET MVC, impartido por Eduard Tomàs, de Raona. Puedes descargar los materiales y volver a ver el evento online.
5. De paso, apúntate también a http://secondnug.com/, un grupo online con muchísima actividad, tanto de desarrollo como de sistemas (aunque yo de sistemas, ya sabes…) Tienen muchísimo material, sobre todo vídeos de charlas.
6. Consejo personal para MVC: En las primeras versiones usaban la sintaxis clásica para las vistas, lo del <% %>, pero ahora tienen una sintaxis nueva llamada Razor. Los archivos en vez de .aspx son .cshtml (o .vbhtml). Aunque puedes escoger entre las dos, te recomiendo entrar en Razor directamente.
7. Y sobre el acceso a datos, no sé si has probado EF, ya va por la versión EF 4.1 (aka CodeFirst). También muy recomendable para iniciarse en MVC, además muchos de los ejemplos combinan EF y MVC, así que matas dos cerdos de un pajarazo.
8. Hay un ejemplo “oficial” con un tutorial muy muy extenso: http://mvcmusicstore.codeplex.com/ Puedes descargarlo para bichearlo, o tratar de hacerlo tú mismo con el tutorial. Se aprende mucho.

Bueno, hay muchos más enlaces pero para eso Google, o mejor, sigue la pista a los blogs de los miembros de Auges, que son todos unos cracks.

Suerte y para cualquier duda aquí me tienes.

Al terminar, se cierra sin mostrar confirmación alguna. Aunque esto puede ser suficiente en algunos casos, vamos a ver como incluir en la instalación las típicas ventanas de Bienvenida, Seleccionar carpeta, Proceso y Fin de la instalación.

En primer lugar, WiX ofrece por separado las interfaces gráficas en la librería WixUIExtension.dll, que debemos incluir en la generación del instalador en la herramienta light con los siguientes parámetros:

light PicaSetup.wixobj -cultures:es-ES -ext WixUIExtension.dll

Con esto tendremos disponibles las ventanas en nuestro instalador, y además en nuestro idioma. Pero para que se usen tenemos que activarlas dentro de la etiqueta Project:

<Property Id="WIXUI_INSTALLDIR" Value="AppDir"/>
<UIRef Id="WixUI_InstallDir" />

Empecemos por el final: la etiqueta UIRef es la que incorpora las ventanas al instalador. Su valor es la plantilla de instalador que queremos usar, en este caso WixUI_InstallDir identifica la típica instalación con Bienvenida, Licencia, Carpeta, Progreso y Fin. Hay otras plantillas

Por otro lado, la etiqueta Property tiene una utilidad auxiliar pero muy importante: asociar el resultado de la ventana donde se selecciona la carpeta destino con el valor usado en el elemento Directory para instalar el producto. De no indicarla, el directorio seleccionado en esa ventana no se usaría después. Debe contener como Value el Id de la etiqueta Directory final donde vamos a instalar. En nuestro ejemplo anterior era AppDir, ya que se corresponde con la carpeta última donde se instalan los componentes.

Con esto ya podemos generar (usando los parámetros de light indicados antes para considerar la librería de UI) y tendremos un instalador totalmente funcional. Pero podemos personalizar su apariencia mediante variables de WiX.

Variables de WiX

Mediante las variables de WiX podemos pasar parámetros para la generación del instalador. Son parámetros para su construcción, no para el momento de la instalación. El valor de estas variables puede establecerse de dos formas:

• En el archivo wxs, mediante un elemento WixVariable dentro de Wix:
  <WixVariable Id=”var” Value=”valor”/>
• Como argumento de línea de comandos de la herramienta light:
  light PicaSetup.wxsobj -dvar=valor

Estas variables pueden ser consumidas también por las extensiones de WiX, y en nuestro caso WixUIExtension.dll acepta unas cuantas de ellas, como WixUIBannerBmp o WixUIDialogBmp.

Cambiando el texto de licencia

Una aplicación práctica, y quizá la más prioritaria en un instalador comercial, se refiere a la ventana de licencia, que por defecto muestra la licencia CPLv2 en inglés:

Esto desentona tanto por el idioma como porque quizá esta no sea nuestra licencia elegida. Para cambiarlo, podemos establecer la variable WixUILicenseRtf con la ruta donde encontrar un archivo RTF con la licencia. Esta variable puede declararse en el archivo wxs:

<WixVariable Id="WixUIDialogBmp" Value="licencia.rtf"/>

o bien como parámetro de la herramienta light:

light PicaSetup.wxsobj -dWixUIDialogBmp=licencia.rtf

En resumen, las posibilidades de configuración del interfaz gráfica del instalador son enormes en WiX, sirva este artículo como sencillo ejemplo de cómo conseguir un instalador decente y muy estándar para nuestras aplicaciones.