Establecer el foco automáticamente, versión declarativa

ASP.NET MVCHace poco escribía un post en el que mostraba cómo se podía conseguir establecer el foco inicialmente en un control de edición, algo que era posible con Webforms pero no directamente con las herramientas que ASP.NET MVC trae de fábrica.

La solución propuesta consistía en introducir en la vista código de script para desplazar el foco hasta el control indicado mediante una llamada al helper Html.SetFocusTo(), que implementábamos en el mismo post, aunque hay otras formas para conseguirlo.

Unos días después, un amigo de Variable not found preguntaba en un comentario si no había una forma de conseguir lo mismo utilizando una sintaxis más declarativa, al estilo de la especificación de metadatos o validadores basados en atributos o data annotations.

En primer lugar he de decir que no creo que sea muy conveniente hacerlo, puesto en casi todos los escenarios posicionar el foco en un elemento es pura presentación, no suele haber decisiones de negocio tras ello, y por tanto no es algo que debamos sacar de la Vista. Pero bueno, independientemente de eso, vamos a ver cómo podríamos conseguirlo.

Una forma relativamente sencilla de hacerlo sería utilizando atributos de metadatos personalizados de forma muy similar al ejemplo que vimos también en un post anterior.

Lo primero que necesitamos es definir un atributo que implemente IMetadataAware, lo que indica que incluye información sobre metadatos, y aprovechar el método OnMetadataCreated() para introducir en la colección de metadatos adicionales una señal que permita más adelante detectar la propiedad a “enfocar”:

public class FocusedAttribute : Attribute, IMetadataAware
{
    public const string MetadataKey = "Focused";
    public void OnMetadataCreated(ModelMetadata metadata)
    {
        metadata.AdditionalValues[MetadataKey] = true;
    }
}

De esta forma, para activar el foco inicialmente sobre el editor de una propiedad concreta, simplemente deberíamos marcarla con el atributo [Focused], como se muestra en el código siguiente:

public class Friend
{
    [Focused]
    public string Name { get; set; }
 
    public string Email { get; set; }
    public string Phone { get; set; }
    public string Fax { get; set; }
 
}

Una vez finalizados los preparativos, tenemos que ver cómo implementarlo en la vista. Lo más sencillo en este caso sería crear el helper Html.Autofocus(), que será encargado de localizar la propiedad con el atributo [Focused] y generar sobre la vista el script que mueva el foco a la misma:

public static class HtmlExtensions
{
    public static MvcHtmlString Autofocus(this HtmlHelper html)
    {
        var template = html.ViewData.TemplateInfo;
        var focusedProperty = 
             (from property in html.ViewData.ModelMetadata.Properties
              where property.AdditionalValues.Any(
                     a => a.Key == FocusedAttribute.MetadataKey && (bool) a.Value)
              select template.GetFullHtmlFieldId(property.PropertyName)
             ).FirstOrDefault();
        if (focusedProperty != null)
        {
            return createAutofocusScript(focusedProperty);
        }
 
        return null;
    }
 
    private static MvcHtmlString createAutofocusScript(string focusedProperty)
    {
        string script = "<script type='text/javascript'>" +
                        "$(function() { $('#" + focusedProperty + "').focus(); });" +
                        "</script>";
        return MvcHtmlString.Create(script);
    }
}

Por último, basta con introducir en la vista la siguiente llamada. O mejor aún, si queremos que esta funcionalidad esté activa en todas las vistas, podemos añadirla al final del Layout que estemos empleando para ellas:

@Html.Autofocus()

Hay que tener en cuenta que nada impide que el atributo Focused sea empleado en más de una propiedad, en cuyo caso el foco se establecerá en la primera ocurrencia localizada. Esto se podría evitar llevando el atributo a nivel de clase e indicando como parámetro el valor de la propiedad (algo así como [DefaultProperty("Name")] sobre la propia entidad). En el proyecto de demostración podréis encontrar también esta implementación.

Descargar proyecto de demostración (VS2010+MVC 3) desde Skydrive.

Publicado en Variable not found.

ASP.NET MVC: WebGrid con filtro, paginación y ordenación

ASP.NET MVCHace unos días, el amigo Cadavid realizaba una consulta en los comentarios de la serie de posts que escribí hace unos meses sobre el helper Webgrid, sobre cómo podíamos implementar filtros personalizados sobre los datos mostrados, y dado que no es algo que se pueda explicar en un simple comentario, me comprometí a escribir un post sobre el tema, así que ahí va.

El problema fundamental es que WebGrid no incorpora ningún tipo de ayuda para realizar esta tarea tan frecuente; simplemente se encarga de mostrar los datos que le suministremos, por lo que si queremos filtrarlos debemos hacerlo de forma manual. En pura teoría bastaría con hacer llegar a Controlador los filtros a aplicar, y que éste consultara la información desde el Modelo teniendo en cuenta los criterios establecidos.

Sin embargo, algo que puede parecer relativamente simple se complica un poco si queremos, además, mantener intacta la capacidad de ordenación y paginación de datos, puesto que debemos encargarnos también del mantenimiento del estado entre peticiones. Pero vaya, no es nada que no podamos solucionar en unos minutos 😉


Partiendo del proyecto que desarrollamos en el último post de la serie vamos a ver cómo podemos añadir al grid un par de criterios de búsqueda, de forma que el resultado luzca tal que así:

Criterios de filtro con Webgrid
El campo Texto nos permitirá buscar subcadenas en el nombre y apellidos de las personas almacenadas en la base de datos, y los otros dos campos permitirán filtrar por rango (mín-máx) los hijos que tienen. Como es habitual, estas condiciones las combinaremos con un Y lógico.

1. La vista

En primer lugar introducimos en la vista, justo antes de generar el grid, el formulario que utilizaremos para solicitar al usuario los criterios de búsqueda:

Cuadro de criterios de búsqueda
El código es el siguiente:

@using(Html.BeginForm(null, null, FormMethod.Get))
{
    <fieldset>
        <legend>Criterios de búsqueda</legend>
        @Html.Label("buscar", "Texto:")
        @Html.TextBox("buscar") 
        @Html.Label("hijosMin", "Hijos mín:")
        @Html.TextBox("minHijos") 
        @Html.Label("maxHijos", "Hijos máx:")
        @Html.TextBox("maxHijos" )
 
        <input type="submit" value="Buscar" />
    </fieldset>
}
Observad la simplicidad del formulario. Por no usar, no usa ni siquiera la sintaxis lambda en los helpers de edición. Los controles vamos generarlos partiendo de campos cuyos valores existirán en el query string, y no desde el Modelo, que es lo habitual, y por esta razón fijaos que el formulario está configurado para ser enviado utilizando el método HTTP GET.

De esta forma podemos propagar muy fácilmente el valor de los controles (textbox) entre las llamadas:

  • si el usuario introduce criterios y pulsa el botón enviar, la URL a la que se realizará la petición será, por ejemplo, /personas/index?buscar=aguilar&hijosMin=0&hijosMax=8.
  • si el usuario utiliza los botones de navegación propios del grid (avance/retroceso de página, salto a página directa, o reordenación), estos parámetros serán añadidos a los anteriores, de forma que seguirán manteniendo sus valores entre las distintas llamadas. Esto es así gracias a que Webgrid genera los enlaces de estas acciones respetando los parámetros actuales del query string; es decir, si estamos filtrando y saltamos a la página 4, accederemos a una dirección que incluirá tanto la información de los criterios de búsqueda como la de paginación, algo como: /personas/index?buscar=aguilar&minHijos=0&maxHijos=8&page=4.
Y con esto, dejamos completada la capa vista.

2. El Controlador

Si recordáis, el método de acción encargado de obtener los datos de grid y enviar la vista con los datos al usuario recibía tres parámetros: la página actual, el campo de ordenación y el sentido de ésta (ascendente/descendente).

Dado que ahora necesitará también obtener los criterios de ordenación, debemos ampliar su definición añadiendo parámetros para estos valores:

public ActionResult Index(int page = 1, string sort = "Apellidos", string sortDir = "ASC", 
                          string buscar = null, int? minHijos = null, int? maxHijos = null)
Observad que son todos parámetros opcionales, y los establecemos a nulo para detectar fácilmente cuándo nos vienen rellenos.

¿Y en qué puntos necesitamos utilizar estos nuevos parámetros? Pues sólo en dos:

  • en la llamada que hacemos al Modelo para contar el total de filas del grid, a la que tendremos que informar sobre los criterios de filtrado para que el conteo se realice correctamente.
  • en la llamada que hacemos al Modelo para obtener las filas a mostrar en la página actual, donde obviamente también deberemos tener en cuenta los filtros.
La acción quedaría más o menos así:

public ActionResult Index(int page = 1, string sort = "Apellidos", string sortDir = "ASC",
                          string buscar = null, int? minHijos = null, int? maxHijos = null)
{
    var numPersonas = _services.ContarPersonas(buscar, minHijos, maxHijos);
    var personas = _services.ObtenerPaginaDePersonasFiltrada(page, PERSONAS_POR_PAGINA, 
                                   sort, sortDir, buscar, minHijos, maxHijos);
 
    var datos = new PaginaDePersonasViewModel()
                    {
                        NumeroDePersonas = numPersonas,
                        PersonasPorPagina = PERSONAS_POR_PAGINA,
                        Personas = personas
                    };
 
    return View(datos);
}
Y esto es todo en el controlador.

3. El Modelo

Y por último, ya en el Modelo, debemos hacer que los métodos utilizados desde el controlador (ContarPersonas y ObtenerPaginaDePersonasFiltrada) tengan en cuenta los parámetros en los que indicamos las condiciones de búsqueda.

En el primero de ellos, simplemente retornamos el número de personas que cumplan los criterios que nos llegan como parámetros:

public int ContarPersonas(string textoBuscar = null, int? minHijos = null, int? 
                          maxHijos = null)
{
    IQueryable<Persona> query = _datos.Personas;
    query = queryPersonasFiltrada(textoBuscar, minHijos, maxHijos, query);
    return query.Count();
}
El método de utilidad queryPersonasFiltrada() que estamos utilizando únicamente se encarga de añadir a la query las cláusulas where que necesitamos para tener en cuenta las condiciones especificadas:

private static IQueryable<Persona> queryPersonasFiltrada(string textoBuscar, int? minHijos, 
                                         int? maxHijos, IQueryable<Persona> query)
{
    if (!string.IsNullOrWhiteSpace(textoBuscar))
        query = query.Where(p => p.Nombre.Contains(textoBuscar) || p.Apellidos.Contains(textoBuscar));
    if (maxHijos != null)
        query = query.Where(p => p.NumeroDeHijos <= maxHijos);
    if (minHijos != null)
        query = query.Where(p => p.NumeroDeHijos >= minHijos);
    return query;
}
Por último, implementamos el método que obtiene los datos a mostrar en la página actual:

public IEnumerable<Persona> ObtenerPaginaDePersonasFiltrada(int paginaActual, int personasPorPagina, 
              string columnaOrdenacion,  string sentidoOrdenacion, 
              string textoBuscar, int? minHijos, int? maxHijos)
{
    // Comprobamos los datos de entrada
    sentidoOrdenacion = sentidoOrdenacion.Equals("desc", StringComparison.CurrentCultureIgnoreCase) ? 
                        sentidoOrdenacion : "asc";
 
    var validColumns = new[] { "apellidos", "fechanacimiento", "email", "numerodehijos" };
    if (!validColumns.Contains(columnaOrdenacion.ToLower()))
        columnaOrdenacion = "apellidos";
 
    if (paginaActual < 1) paginaActual = 1;
    if (personasPorPagina < 1) personasPorPagina = 10;
 
    // Generamos la consulta
    var query = (IQueryable<Persona>) _datos.Personas
                     .OrderBy("it." + columnaOrdenacion + " " + sentidoOrdenacion);
 
    query = queryPersonasFiltrada(textoBuscar, minHijos, maxHijos, query);
 
    return query
            .Skip((paginaActual - 1) * personasPorPagina)
            .Take(personasPorPagina)
            .ToList();
}

Hay poco que comentar sobre este código. En primer lugar se realiza una comprobación básica de los parámetros de entrada, para a continuación generar la consulta que se realizará sobre la base de datos. Como podéis observar, también se utiliza el método queryPersonasFiltrada() para aplicar los criterios de consulta.

En resumen…

Como hemos podido ver, la implementación de criterios de búsqueda en un WebGrid no difiere mucho de la que habíamos descrito en su momento. Sólo hay que tener en cuenta los siguientes puntos:
  • primero, incluir en la Vista un formulario donde se recojan los criterios de la consulta para enviarlos al controlador.
  • segundo, preparar el Controlador para que reciba estos criterios y los haga llegar al Modelo.
  • tercero, en el Modelo, simplemente aplicar esos criterios en el momento de contar las filas totales, y en la obtención de los datos a mostrar en la página del grid.
En SkyDrive he colgado un proyecto que incluye un ejemplo completo donde podéis ver todo esto en funcionamiento: WebGridFiltradoDemo (MVC 3 + SQL Express).

Publicación original (5-oct-2011): http://www.variablenotfound.com/2011/10/aspnet-mvc-webgrid-con-filtro.html

Este artículo y muchos más en: Variable not found.

Referenciar scripts, estilos y otros recursos desde vistas MVC

ASP.NET MVC Una cuestión que consultan frecuentemente los alumnos del curso de MVC que tutorizo en CampusMVP, y que veo en los foros oficiales del framework trata sobre el uso correcto de rutas hacia recursos utilizados por las páginas, como scripts, estilos o imágenes.

Unas referencias erróneas hacia las páginas de estilo o imágenes pueden hacer que un sitio web, o parte de éste, deje de visualizarse correctamente; en el tema de scripts es más grave pues en el peor de los casos el sistema puede dejar de funcionar o presentar un comportamiento anómalo, sobre todo si se hace uso intensivo de bibliotecas como jQuery o MS Ajax.

Para mayor desgracia, muchas veces la aparición de estos síntomas es tardía. Todo parece funcionar correctamente en desarrollo, con el servidor integrado de Visual Studio, y falla estrepitosamente al publicarlo en el IIS de producción, lo cual puede provocar un cierto nerviosismo y la aparición de frases como “¡en mi máquina funciona!” ;-).

¿Y por qué es tan habitual encontrar problemas en esto, a priori tan sencillo? En mi opinión, por las prisas y la comodidad, sin duda malas compañías para los desarrolladores. Y conste que no seré yo quien tire la primera piedra…

Sin duda es realmente cómodo arrastrar un recurso (script, estilo…) desde el explorador de proyectos y dejarlo caer sobre una vista; Visual Studio es lo suficientemente inteligente como para generar la etiqueta apropiada para referenciarlo.

Por ejemplo, editando el archivo /Views/Home/Index.aspx, podemos arrastrar directamente el archivo /Content/Site.css y el entorno generará un tag <link> completo:

Arrastrar recurso sobre una vistaSin embargo, si nos fijamos bien, la ruta que está creando hacia el recurso no es del todo correcta.

En tiempo de diseño el entorno no sabe qué URL será utilizada para acceder a la página, por lo que incluye en el código es la ubicación relativa del recurso respecto a la ubicación de la vista actual en el sistema de archivos.

Por ello, en el ejemplo anterior, editando el archivo /Views/Home/Index.aspx ha generado la ruta relativa hacia la carpeta Content, que incluye dos saltos hacia arriba en la estructura de carpetas para llegar al raíz, más el acceso al archivo desde éste.

Esto puede ser válido si estamos editando páginas en un entorno en el que las peticiones son mapeadas directamente contra el sistema de archivos, pero no en MVC, donde las rutas son tan fácilmente manipulables.

De la misma forma, tampoco sería válido en escenarios WebForms donde la ubicación de la página no coincida con la de la petición actual, como las páginas maestras o controles de usuario, o si utilizamos las nuevas capacidades de routing de .NET 4.

Volviendo de nuevo al ejemplo anterior, aunque la vista esté implementada en el archivo  /Views/Home/Index.aspx, el acceso a la misma podría realizarse, utilizando la ruta por defecto, mediante la URL http://servidor/, lo que implica que la referencia relativa de la hoja de estilos estaría saliéndose del ámbito de la aplicación, es decir, se estaría intentando acceder dos niveles por arriba de la carpeta de publicación del proyecto.

En el servidor web integrado en Visual Studio nuestra aplicación funcionará correctamente al ignorar los intentos de subir más allá del raíz de la aplicación, lo que retrasa la detección del problema. Al publicar en IIS, bastante menos permisivo, nos encontraremos con que nuestra aplicación ha dejado de funcionar.

Afortunadamente hay soluciones para todos los gustos. De hecho, más que soluciones para cuando aparezca el problema, deberíamos tomarlas como buenas prácticas a la hora de referenciar cualquier tipo de elemento desde el principio del desarrollo.

Veamos algunas de ellas.

Solución 0: Cambiar las rutas a mano

La “solución” más artesana es, sin duda, introducir manualmente las rutas en todas las referencias hacia recursos externos de la vista. De hecho, en realidad nos puede ayudar a solucionar el problema descrito anteriormente, pero es bastante poco flexible, y no muy recomendable.

Así, el ejemplo anterior podríamos editar el código generado por Visual Studio y sustituirlo por el siguiente:

<link href="/Content/Site.css" rel="stylesheet" type="text/css" />

Como observaréis, hemos eliminado la porción “../../” de la ruta, por lo que la hoja de estilos ya estaría referenciada correctamente, ¿no?

Pues depende. Si nuestra aplicación se publica en el raíz de un dominio o subdominio, todo será correcto; en cambio, si queremos desplegarla en un directorio ya la hemos vuelto a liar, puesto que la referencia asume que la carpeta “Content” se encuentra en el raíz.

Por experiencia, suele ser bastante habitual que durante el desarrollo de una aplicación se cuelguen versiones de demostración en directorios privados, y una vez terminada se pasen al raíz de su dominio. Ante este escenario, si las rutas las hemos indicado de forma absoluta, en vez de una solución, hacer este cambio es sólo introducir una nueva fuente de problemas.

Solución 1: Usar el helper Url.Content()

El helper Url.Content() nos permite obtener la URL del recurso cuya ubicación física estamos pasándole como parámetro. Dado que el resultado se calcula en tiempo de ejecución, el framework ya dispone de información suficiente para generar la dirección correcta.

La forma de usarlo, muy sencilla. Observad el uso del gusanillo “~” para hacer referencia al directorio raíz de la aplicación:

<link href="<%= Url.Content("~/Content/Site.css")%>" rel="stylesheet" type="text/css" />
<script src="<%= Url.Content("~/Scripts/jquery-1.4.1.js")%>" 
        type="text/javascript" /></script>

Este enfoque sí aporta una solución definitiva al problema, aunque a la hora de codificarlo sea algo tedioso.

Solución 2: usar T4MVC

Otra alternativa, sin duda interesante, para generar la ruta correcta es utilizar la magnífica herramienta T4MVC, de la que ya hemos hablado por aquí algunas veces. Muy resumidamente, T4MVC es una plantilla de generación de código automático capaz de analizar el contenido de nuestro proyecto y generar “constantes” que nos permitan eliminar los literales de texto en las aplicaciones MVC.

Así, por ejemplo, tras su inclusión en nuestro proyecto, la propiedad pública  Links.Content.Site_css contendrá la ruta correcta hacia el archivo ~/Content/Site.css, calculada en tiempo de ejecución, por lo que podríamos dejar el código anterior en:

<link href="<%= Links.Content.Site_css %>" rel="stylesheet" type="text/css" />
<script src="<%= Links.Scripts.jquery_1_4_1_js %>" 
        type="text/javascript" /></script>

Observad que hemos eliminado la llamada a Url.Content(), puesto que ya las propiedades utilizadas están calculando la ruta correcta.

Una ventaja adicional de T4MVC es que podría detectarse en tiempo de compilación la ausencia de un archivo. Si después de introducir el código anterior eliminamos los archivos referenciados, al compilar la vista se produciría un error. Además, durante la codificación podemos disfrutar de intellisense para descubrir los archivos y evitar errores.

Solución 3: Crear nuestros propios helpers

Ya sabemos que el framework ASP.NET MVC está, desde sus inicios, preparado para ser fácilmente extendido, y los helpers Html de las vistas no iban a ser la excepción.

Si por cualquier extraño e incomprensible motivo no quieres o puedes utilizar T4MVC, siempre podrías construirte tus propios helpers. En el siguiente ejemplo, vemos cómo con un par de llamadas podríamos simplificar la generación de las etiquetas de referencia a scripts y estilos en una página:

<head>
<title>Mi sitio web</title>
<%= Html.IncludeStyles("site.css", "ui.jqgrid.css", "redmond/jquery-ui-1.8.2.custom.css")%>
<%= Html.IncludeScripts("jquery-1.4.1.min.js", "jquery-ui-1.8.2.custom.min.js", 
                        "grid.locale-sp.js", "jquery.jqGrid.min.js")%>
</head>

Como se puede intuir, estos helpers generarán las etiquetas <style> y <script> correspondientes para todos los archivos que se les suministre como parámetros. El código, el siguiente:

 
public static class HtmlIncludeHelpers
{
    public static MvcHtmlString IncludeScripts(this HtmlHelper html, 
                                               params string[] scriptNames)
    {
        return generateContent(
                    html,
                    @"<script type=""text/javascript"" src=""{0}""></script>",
                    "~/Scripts/",
                    scriptNames
        );
    }
 
    public static MvcHtmlString IncludeStyles(this HtmlHelper html, 
                                              params string[] fileNames)
    {
        return generateContent(
                    html,
                    @"<link href=""{0}"" rel=""stylesheet"" type=""text/css"" />",
                    "~/Content/",
                    fileNames
        );
    }
 
    private static MvcHtmlString generateContent(HtmlHelper helper, string tag, 
                                                 string root, IEnumerable<string> files)
    {
        StringBuilder sb = new StringBuilder();
        if (files != null)
        {
            string path = UrlHelper.GenerateContentUrl(root, helper.ViewContext.HttpContext);
            foreach (var file in files)
            {
                sb.AppendFormat(tag, Path.Combine(path, file));
            }
        }
        return MvcHtmlString.Create(sb.ToString());
        
    }
}

(He dejado este código en Skydrive).

En definitiva, existen mil y un patrones que podemos utilizar para evitar problemas en la generación de rutas hacia los recursos de una página. Espero que lo planteado en este post puedan seros de ayuda a la hora de diseñar vuestra propia solución.

Publicado en: Variable not found.

ASP.NET MVC 2: Quince cuestiones que deberías conocer

10 Preguntas con respuesta ASP.NET MVC En marzo de 2008 publiqué un megapost en el que se recogían respuestas a diez preguntas básicas sobre el framework ASP.NET MVC, que por aquellos entonces se encontraba todavía en una versión muy preliminar, la Preview 2.

Más de un año después, coincidiendo con el lanzamiento de la versión 1.0, actualicé el contenido y las preguntas conforme a la evolución de los desarrollos y a lo que había podido profundizar en el tema desde entonces, en el post ASP.NET MVC: Trece preguntas básicas.

Y de nuevo en 2010, continuando lo que ya parece que es una tradición, aprovecho el reciente lanzamiento de ASP.NET MVC 2 para actualizar las respuestas y añadir algunas nuevas cuestiones básicas que pienso pueden resultar de interés a desarrolladores que todavía no conocen este nuevo marco de trabajo de Microsoft.

Trataré de responder a las siguientes preguntas:

  1. Empecemos desde el principio, ¿qué es MVC?
  2. ¿Qué ventajas tiene el uso del patrón MVC?
  3. ¿Qué es ASP.NET MVC framework?
  4. Espera… pero entonces, ¿programar con ASP.NET MVC no consiste en usar Webforms, pero separando los componentes en capas?
  5. ¿Es el primer framework MVC creado para .NET?
  6. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?
  7. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?
  8. Pero… ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?
  9. Siempre que leo algo sobre MVC viene rodeado de un gran número de conceptos extraños como IoC o DI. ¿Es que ASP.NET MVC es sólo para gurús?
  10. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?
  11. ¿Se puede utilizar Ajax con el framework MVC?
  12. ¿Se puede utilizar VB.NET con ASP.NET MVC?
  13. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?
  14. ¿Qué tipo de tecnologías puedo utilizar en las vistas?
  15. ¿Es ASP.NET MVC framework software libre?
El post es un poco extenso, así que mejor que os pongáis cómodos… 😉
Continuar leyendo en: http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html

¿ActionLink te genera direcciones que acaban en Length=N?

ASP.NET MVC Esta es una respuesta rápida a una cuestión de Fred C., que me llega vía formulario de contacto en Variable not found, sobre un problemilla que también sufrí en algunas ocasiones, y he pensado que posiblemente pueda interesarle a alguien más, así que ahí va.

El escenario es el siguiente: tenemos en una vista un código para generar un enlace hacia una acción, como el mostrado a continuación:

<%= Html.ActionLink("Acceso externo",    // Texto del enlace
                    "Editar",            // Acción
                    "Productos",         // Controlador
                    new { id=Model.Id }) // Parámetros
%>
ActionLink() generan
Al mostrarse la vista, ya en tiempo de ejecución, nos encontramos con que no se ha generado el enlace que pretendíamos, sino uno como el mostrado en la captura de pantalla adjunta, hacia la dirección/Home/Editar?Length=9.

En primer lugar, utilizando la ruta por defecto, vemos nos está llevando hacia el controlador “Home”, ¿pero no le habíamos dicho que era “Productos”?

Y en segundo lugar, ¿dónde está nuestro parámetro id? ¿De dónde sale ese parámetro Length con el valor 9?

La respuesta a este problema es bien sencilla aunque al principio puede provocarnos algún dolor de cabeza: estamos utilizando una sobrecarga incorrecta del método ActionLink().

Si observamos las distintas sobrecargas de este método, podremos comprobar que sólo una de ellas tiene una signatura compatible con la llamada que estamos utilizando:

public static string ActionLink(
    this HtmlHelper htmlHelper,
    string linkText,
    string actionName,
    object routeValues,
    object htmlAttributes
)
Así, cuando en el código anterior estábamos pasando al método el nombre del controlador, en realidad lo que hacíamos era indicarle los parámetros de la llamada. Eso explica el parámetro Length=9 en la URL: dado que le enviamos un string de 9 caracteres, simplemente se trata de una serialización de sus propiedades.

Y, por tanto, los parámetros de la llamada que estábamos especificando, lo hacíamos como parte de los atributos HTML. De hecho, si analizamos el código fuente de la página generada, encontramos que el parámetro “id” ha sido introducido como un atributo HTML del enlace:

<a href="/Home/Editar?Length=9" id="8">Editar este producto</a>
La forma de solucionarlo es bien fácil, sólo hay que utilizar la sobrecarga apropiada, como:

<%= Html.ActionLink("Editar este producto", 
            "Editar",                     // Acción
            new {                         // Parámetros
            controller="Productos", 
            id=Model.Id 
}
) %> 
 
// O Bien:
 
<%= Html.ActionLink(
             "Editar este producto", 
             "Editar",               // Acción  
             "Productos",            // Controlador
             new { id=Model.Id },    // Parámetros
             null                    // Atributos HTML
) %> 
En fin, que se trata de un pequeño despiste a la hora de codificar, propiciado a veces por la gran cantidad de sobrecargas y la información, algo confusa, ofrecida por Intellisense que nos puede hacer perder unos minutos muy valiosos.

¡Gracias, Fred, por participar en Variable not found!

Post original: ¿ActionLink te genera direcciones que acaban en Length=N?
Por cierto, ¡estoy en Twitter!

ASP.NET MVC: trece preguntas básicas

 

10 Preguntas con respuesta ASP.NET MVC En marzo de 2008 publiqué un post en el que se recogían respuestas a diez preguntas básicas sobre el framework ASP.NET MVC, que por aquellos entonces se encontraba todavía en una versión muy preliminar, la Preview 2.

Más de un año después, coincidiendo con el reciente lanzamiento de la versión 1.0, voy a actualizar el contenido y las preguntas conforme a la evolución de los desarrollos y a lo que he podido profundizar en el tema desde entonces.

Las cuestiones que trataré son las siguientes:

  1. Empecemos desde el principio, ¿qué es MVC?
  2. ¿Qué ventajas tiene el uso del patrón MVC?
  3. ¿Qué es ASP.NET MVC framework?
  4. ¿Es el primer framework MVC creado para .NET?
  5. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?
  6. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?
  7. ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?
  8. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?
  9. ¿Se puede utilizar ASP.NET Ajax con el framework MVC?
  10. ¿Se puede utilizar VB.NET con ASP.NET MVC?
  11. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?
  12. ¿Qué tipo de tecnologías puedo utilizar en las vistas?
  13. ¿Es ASP.NET MVC framework software libre?

1. Empecemos desde el principio, ¿qué es MVC?

Aunque de forma algo simplista, podríamos definir MVC como un patrón arquitectural que describe una forma de desarrollar aplicaciones software separando los componentes en tres grupos (o capas):

  • El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.
  • La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste.
  • El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.

MVC son las siglas de Modelo-Vista-Controlador, y se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo.

Puedes encontrar más información en:

2. ¿Qué ventajas tiene el uso del patrón MVC?

Como siempre, esto de enumerar ventajas es algo subjetivo, por lo que puede que pienses que falta o sobra alguna dímelo!). En un primer asalto podríamos aportar las siguientes:

  • Clara separación entre interfaz, lógica de negocio y de presentación, que además provoca parte de las ventajas siguientes.
  • Sencillez para crear distintas representaciones de los mismos datos.
  • Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD).
  • Reutilización de los componentes.
  • Simplicidad en el mantenimiento de los sistemas.
  • Facilidad para desarrollar prototipos rápidos.
  • Los desarrollos suelen ser más escalables.

Pero bueno, también se pueden citar algunos inconvenientes:

  • Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC.
  • La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos más simples como Webforms.
  • La distribución de componentes obliga a crear y mantener un mayor número de ficheros.

3. ¿Qué es ASP.NET MVC Framework?

Plantilla de aplicación ASP.NET MVC Es un framework, un entorno de trabajo cuya primera versión acaba de ver la luz, creado por Microsoft con objeto de ayudarnos a desarrollar aplicaciones que sigan la filosofía MVC sobre ASP.NET.

Además del conjunto de librerías (ensamblados) que proporcionan las nuevas funcionalidades a nivel de API, incluye plantillas y herramientas que se integran en Visual Studio 2008 (tanto en la versión Express de Visual Web Developer como en sus hermanas mayores) para facilitarnos un poco las cosas.

Una vez instalado el marco de trabajo (que puedes iniciar desde aquí o desde el Web Platform Installer), Visual Studio mostrará un nuevo tipo de proyecto (ASP.NET MVC Web Application) que nos permitirá crear el esqueleto básico de un proyecto de este tipo. Y ya para cuando estemos en faena, el entorno ofrece multitud de utilidades para hacer nuestro trabajo más fácil, como la herramienta de creación de vistas automáticas, el desplazamiento entre controladores y vistas, o plantillas para la definición de controladores, entre otras.

4. ¿Es el primer framework MVC creado para .NET?

No, ni el único. Existen multitud de frameworks MVC para ASP.Net, como MonoRail, Maverick.Net, ProMesh.Net y muchos otros.

5. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?

No necesariamente. Puedes seguir desarrollando aplicaciones como hasta ahora, con Webforms. Si así lo decides, este nuevo framework no te afectará nada; simplemente, ignóralo.

De todas formas, ya que has leído hasta aquí, permíteme un consejo: aprende a utilizar ASP.NET MVC framework. Después podrás decidir con conocimiento de causa si te conviene o no.

6. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?

Diseñador de Webforms En absoluto. Son simplemente dos filosofías diferentes para conseguir lo mismo, ¡páginas web!

La tecnología de Webforms es muy útil para asemejar el desarrollo de aplicaciones web a las de escritorio, ocultando la complejidad derivada del entorno desconectado y stateless (sin conservación de estado) del protocolo HTTP a base de complejos roundtrips, postbacks y viewstates, lo que nos permite crear de forma muy productiva formularios impresionantes y que el funcionamiento de nuestra aplicación esté guiado por eventos, como si estuviéramos programando Winforms.

Sin embargo, esta misma potencia a veces hace que las páginas sean pesadas y difícilmente mantenibles, además de dificultar enormemente la realización de pruebas automatizadas. Y por no hablar de comportamientos extraños cuando intentamos intervenir en el ciclo de vida de las páginas, por ejemplo para la carga y descarga de controles dinámicos.

ASP.NET MVC propone una forma distinta de trabajar, más cercana a la realidad del protocolo y, curiosamente, más parecida a cómo se hacía unos años atrás, cuando controlábamos cada byte que se enviaba al cliente o se recibía de éste. No existen, por tanto, conceptos como el mantenimiento del estado en el viewstate, ni el postback, ni nos valdrán los controles de servidor basados en estas características, que son la mayoría. Sin embargo, dado que el framework está creado sobre ASP.NET, será posible utilizar páginas maestras, codificar las vistas en un .aspx utilizando C# o VB.NET, usar los mecanismos de seguridad internos, control de caché, gestión de sesiones, localización, etc.

7. ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?

En mi opinión, probablemente no se trate de decidirse por una u otra tecnología, sino de conocer ambas y utilizar la más apropiada en cada momento. Hay muchos aspectos a tener en cuenta, por citar algunos:

Vamos a reflexionar sobre cada uno de estos puntos, y la decisión os la dejo a vosotros. 😉

El equipo de desarrollo

image

La tecnología de formularios web (Webforms) permite el desarrollo rápido de aplicaciones (RAD) a través de diseñadores visuales con los que es posible componer una página compleja y definir el comportamiento del interfaz a golpe de ratón, puesto que el framework se encarga de realizar parte del trabajo duro, como el mantenimiento del estado entre peticiones, convertir propiedades de controles en código HTML y CSS, o incluso generar scripts que realicen determinadas tareas en cliente. De hecho, siguiendo este modelo es posible crear aplicaciones para Internet sin tener apenas idea de las particularidades inherentes al desarrollo web, lo que permite que muchos programadores procedentes del mundo del escritorio puedan ser productivos muy rápidamente, aunque sea a costa de generar páginas mucho más pesadas y con un código de marcado complejo.

No hay que olvidar que para determinado tipo de aplicaciones, los Webforms son una buena opción, tanto como lo han sido hasta ahora. Por tanto, si el equipo de desarrollo tiene ya experiencia creando aplicaciones con esta tecnología y no poseen grandes conocimientos sobre programación web de más bajo nivel ni experiencia previa trabajando con el patrón MVC, deberíamos pensárnoslo antes de dar el salto a ASP.NET MVC, puesto que la productividad, al menos inicialmente, va a caer.

ASP.NET MVC requiere un conocimiento más profundo del entorno web y sus tecnologías subyacentes, puesto que a la vez que ofrece un control mucho más riguroso sobre los datos que se envían y reciben desde el cliente, exige una mayor responsabilidad por parte del desarrollador, ya que deberá encargarse él mismo de mantener el estado entre peticiones, maquetar las vistas, crear las hojas de estilo apropiadas, e incluso los scripts. Esto, sin embargo, no difiere mucho de la forma de trabajar unos años atrás, y es posible que en el equipo de trabajo haya desarrolladores experimentados que se sientan incluso más cómodos trabajando a este nivel que utilizando abstracciones como las provistas por ASP.NET Webforms.

Controles y módulos reutilizables

Otro aspecto a valorar antes de dar el salto a ASP.NET MVC es que existe una altísima probabilidad de que no podamos utilizar sistemas o componentes que hayamos desarrollado previamente, lo cual redundará en los tiempos de desarrollo y productividad del equipo de trabajo. No nos valdrán los controles de servidor, ni las plantillas de proyectos, ni los generadores de código, y en muchos casos ni siquiera la herencia de editor (que por muy antipatrón que sea seguro que acostumbramos a utilizar).

Probablemente en breve dispondremos de componentes para ASP.NET MVC generados por la propia comunidad de desarrolladores, ya sea en forma de helpers (métodos estáticos de generación de código en cliente), en forma de vistas parciales (por ejemplo en archivos .ASCX) y nos permitan reutilizar código, o incluso como controles de servidor (ya se puede ver algo de eso en el ensamblado MVC Futures, disponible en CodePlex).

Puedes ver un ejemplo de helper en el post “Helper para desplegables enlazados con ASP.NET MVC y jQuery”.

Madurez del framework

ASP.NET MVC es un framework recién salido del horno, por lo cual su adopción implica ciertos riesgos, ya superados por los veteranos Webforms.

En primer lugar, es bastante probable que durante un primer periodo de adopción comiencen a surgir bugs, agujeros de seguridad y otros problemas que podrán hacer tambalear los cimientos de los sistemas que utilicen este marco de trabajo. También es cierto que dada la disponibilidad del código fuente del mismo y su relativa simplicidad frente a los formularios web, los inconvenientes que puedan aparecer podrían ser rápidamente subsanados.

La madurez también se hace patente en la cantidad y calidad de información disponible. ASP.NET MVC, aunque cuenta con una comunidad de desarrolladores bastante entusiasta, son una minoría comparándola con su veterana competencia.

Y lo mismo ocurre con el número ingente de componentes y controles reutilizables disponibles para Webforms. Dado que no son compatibles con el framework MVC, se parte de una situación de clara desventaja frente a éstos, aunque como comentaba anteriormente seguro que con el tiempo este aspecto irá mejorando.

Consideraciones sobre el futuro de la tecnología

Si lo que te preocupa es el futuro de los Webforms, has de saber que Microsoft va a seguir dándoles soporte y mejorándolos, como no podía ser de otra forma. Por tanto, de momento no es necesario que bases tu decisión en esto.

Eso sí, hay quien opina que ASP.NET MVC será el estándar de creación de sistemas web en unos años, por lo que en cualquier caso se trata de una tecnología que no habría que perder de vista…

Beneficios de ASP.NET MVC

Las ventajas de la arquitectura MVC, descritas anteriormente, y las bondades del diseño del framework son un buen aliciente para comenzar a trabajar con ASP.NET MVC. De hecho, deberíamos tener muy en cuenta en qué aspectos nuestros desarrollos van a beneficiarse del uso de esta tecnología y valorar si estas ventajas compensan los inconvenientes que su adopción va a suponer:

  • la separación de aspectos impuesta por el patrón MVC obligará a tener un código más limpio y estructurado, independizando totalmente la interfaz de la lógica de navegación y, por supuesto, de la de negocio.
  • de la misma forma, esta división facilita el trabajo en equipo, pues permite el avance en paralelo en las distintas capas.
  • si entre nuestras prioridades está el asegurar el correcto funcionamiento de nuestros componentes a través de pruebas unitarias, o hemos optado por utilizar una metodología de desarrollo guiado por pruebas (TDD), ASP.NET MVC nos vendrá de perlas. La separación de aspectos citada anteriormente facilita la creación de pruebas específicas para los componentes de cada capa de forma independiente, así como el uso de técnicas avanzadas (mocking, inyección de dependencias…) para que éstas sean lo más completas posible.
  • las friendly URLS, o direcciones amigables, es un beneficio directo del uso del framework de Microsoft. Estrictamente hablando no es mérito de la plataforma MVC, sino del juego de clases presentes en el espacio de nombres System.Web.Routing, incluidas en .NET framework 3.5, pero en cualquier caso si optamos por esta tecnología la tendremos “de serie”, con las ventajas que ello conlleva (SEO, REST, claridad en direcciones…).
  • al final, el software será mucho más mantenible; el hecho de que los componentes estén separados y bien estructurados simplificará las tareas de mantenimiento.
  • el conjunto de convenciones en cuanto a la estructura de proyectos y de nombrado y disposición de elementos facilitará el desarrollo una vez sean asimiladas.

El tipo de sistema

A la hora de plantearse un cambio de este tipo es imprescindible tener en cuenta el tipo de proyecto en el que solemos trabajar. No es lo mismo desarrollar un sitio web colaborativo destinado a un gran número de usuarios, como Facebook o Digg, donde el control fino sobre la entrada y salida es crucial para asegurar aspectos como la escalabilidad, cumplimiento de estándares, o accesibilidad, que crear una aplicación de gestión que utilizarán un grupo relativamente reducido de usuarios desde una intranet corporativa.

Para el primer caso, ASP.NET MVC es una buena opción. La simplicidad de la arquitectura MVC hace que el ciclo de vida de las páginas de este framework sea mucho más sencillo que el de los Webforms, y la ausencia de automatismos y persistencia de estado aligera en gran medida el peso y complejidad de las páginas, lo cual redundará muy positivamente en el rendimiento del sistema. Si además el proyecto requiere o resulta beneficiado por el uso de direcciones URL amigables (por razones de SEO, para presentar un interfaz claro de tipo REST, o cualquier otro motivo), más aún.

Un ejemplo de aplicación real de este tipo es la famosa comunidad StackOverflow.

En cambio, el segundo caso, cuando se trata de crear pesadas aplicaciones de gestión con interfaces de usuario complejos y en las que no es especialmente relevante la calidad del código HTML enviado al cliente, ni el peso de éstas al ser entornos cerrados y controlados, ASP.NET Webforms sigue siendo la opción más razonable. Las facilidades para el desarrollo rápido de aplicaciones (RAD) son mayores utilizando formularios web, aunque sea a cambio de sacrificar aspectos como la separación de código e interfaz, o la facilidad para realización de pruebas unitarias.

8. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?

Sí, pero tardarás un buen rato 😉

Al menos que conozca, no existe ninguna herramienta ni siquiera capaz de intentar realizar tal proeza. Hay que tener en cuenta que el cambio de una a otra tecnología no es una mera traducción como podría ser convertir una aplicación VB.NET a C#; se trata de un nuevo marco de trabajo que afecta sobre todo a la presentación y control de flujo del sistema.

Si tienes unas buenas clases de lógica de negocio, bien aisladas de la tecnología Webforms (como debería ser, por otra parte), probablemente sean los únicos componentes que puedas reutilizar de forma directa, sin grandes cambios. El resto, es decir, todo lo relativo a la interacción con el usuario, habría que convertirlo de forma manual, y por tanto, probablemente habría que pensarse bien si vale la pena hacerlo.

9. ¿Se puede utilizar ASP.NET Ajax con el framework MVC?

Si nos estamos refiriendo a la posibilidad de utilizar controles de servidor Ajax, como el célebre UpdatePanel o los controles del ASP.NET Ajax Control Toolkit, la respuesta es rotunda: no. De hecho, el modelo MVC no permite el uso de controles de servidor (runat="server"); bueno, o al menos no lo permite de la forma en que veníamos haciéndolo, pues han dejado de existir aspectos tan fundamentales para ellos como el viewstate o los postbacks.

Ahora bien, si la pregunta la generalizamos como “¿se pueden utilizar librerías Ajax con el framework MVC?” la respuesta es absolutamente. De hecho, ASP.NET MVC se lleva de fábula con librerías de scripting como las incluidas en el framework ASP.NET 3.5, o con la magnífica jQuery. La limpieza de la filosofía MVC hace posible que sea realmente sencillo realizar desde cliente llamadas a los controladores mediante scripting con objeto de obtener datos, actualizar porciones de contenido de la página con el marcado de la vista correspondiente, o, en definitiva, interactuar con el servidor.

En este mismo blog puedes encontrar multitud de ejemplos de integración de jQuery y ASP.NET MVC, que aunque implementados con las previews del framework (¡a ver si un día tengo un rato y los voy actualizando!), pueden ayudarte a entender cómo hacerlo.

Otro aspecto interesante respecto a jQuery es que esta librería entró a formar parte de la plataforma de desarrollo de Microsoft el pasado mes de septiembre, lo que en la práctica aporta varias ventajas: la primera, que jQuery viene incluido de serie en las plantillas de proyectos ASP.NET MVC; la segunda, que Microsoft se ha esforzado por mejorar la integración con Visual Studio de esta librería, facilitando archivos que hacen posible el disfrute de intellisense mientras la utilizamos.

10. ¿Se puede utilizar VB.NET con ASP.NET MVC?

Por supuesto. Aunque la mayoría de código que se encuentra por la red utiliza C#, probablemente porque es el lenguaje en el que ha sido desarrollado y sobre el que se están exponiendo más ejemplos desde las previews más tempranas, cualquier lenguaje .NET podría ser utilizado sin problema para desarrollar aplicaciones sobre este framework.

A nivel de entorno de desarrollo, Visual Basic ofrece el mismo nivel de ayudas y plantillas que C#, pero desconozco si esto es así en otros lenguajes.

11. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?

Sí, de hecho se complementan a la perfección.

Aunque LINQ como tal sólo es un mecanismo de consulta integrado en los lenguajes de programación, las tecnologías ORM que lo rodean, como LINQ2SQL o Entity Framework son ideales para implementar los componentes propios del Modelo (la M de “MVC”). En aplicaciones relativamente simples, estas clases podrían generarse con los diseñadores visuales del entorno de desarrollo, o de forma externa con herramientas como SQLMetal, facilitándonos enormemente el trabajo.

Este es un buen momento para comentar que una de las grandes críticas que se están haciendo a la implementación del framework ASP.NET MVC es que parece hacer olvidado la “M”. Si bien el marco de trabajo establece con claridad el alcance y responsabilidades de los controladores y las vistas y dota de herramientas y convenciones específicas a cada una de estas capas, no ocurre lo mismo con el Modelo, que queda totalmente al libre albedrío del desarrollador.

12. ¿Qué tipo de tecnologías puedo utilizar en las vistas?

El objetivo de las vistas es componer el interfaz de usuario y los mecanismos de interacción con el usuario. Lo habitual será utilizar XHTML, CSS y Javascript, aderezado con bloques de código de servidor que se ejecutará en el momento de renderizar la página.

También puedes utilizar la tecnología Ajax para enviar u obtener información desde el servidor, siempre mediante llamadas a acciones definidas en el controlador, que te permitirán crear interfaces más dinámicos y actuales.

Pero sobre todo, nada de utilizar controles de servidor (Label, Button, Dropdowns…). Estos deberán ser sustituidos por sus elementos XHTML equivalentes, lo que implica que perderemos los automatismos provistos por Webforms para el mantenimiento del estado de los controles.

 

 

<for each="var name in names">
<test if="name == 'Jose'">
<p>Yo mismo</p>
<else/>
<p>Amigo: ${name}
</test>
</for>

Otra posibilidad interesante que aprovecha y demuestra la flexibilidad de la arquitectura de ASP.NET MVC framework, es la utilización de motores de vistas distintos al estándar. Existen multitud de motores ligeros (NHaml, Spark, Brail, NVelocity…), cada uno con su propio lenguaje de marcas y convenciones, que permiten la definición de vistas a partir de plantillas como la que se muestra en el lateral (ejemplo de Spark). 

13. ¿Es ASP.NET MVC framework software libre?

He aquí una de las grandes novedades respecto al post que escribí un año atrás. Por aquellos tiempos era inimaginable que esta pregunta pudiera responderse de forma afirmativa, pero… efectivamente, ASP.NET MVC Framework es software libre.

A primeros de abril de 2009 se comenzó a distribuir oficialmente el código fuente de ASP.NET MVC con licencia MS-PL (Microsoft Public License), un modelo de licencia aprobado por la OSI (Open Source Initiative) que permite el uso del software en aplicaciones comerciales y no comerciales.

Crossposting desde Variable not found

Cómo convertir clases en diccionarios clave/valor

Cuestiones enviadas por lectoresEl otro día, a raíz del post Atajo para instanciar tipos anónimos en C# y VB.NET, el amigo Leo H., desde Argentina, me envió una cuestión:


[…] Me parece muy interesante crear diccionarios utilizando tipos anónimos, pues simplifica de una forma considerable la cantidad de código que hay que escribir para conseguir llenar una estructura de este tipo. De hecho, estoy pensando en utilizar esta técnica en una librería que estoy desarrollando, pero no veo claro cómo transformar después ese objeto anónimo en el diccionario equivalente […]


Verás que la idea es muy simple. Sólo necesitamos encontrar una fórmula que nos permita recorrer las propiedades del objeto, y por cada una de ellas, añadir la entrada correspondiente en el diccionario, especificando como clave el nombre de la propiedad y como valor el que tenga establecido la misma.

Una posibilidad muy sencilla es usar la clase TypeDescriptor, cuyo método GetProperties() nos devuelve una colección con los descriptores de las propiedades de la instancia que le pasemos como parámetro. Iterando sobre este conjunto, podremos ir llenando el diccionario con los elementos que nos interese, tal que así, dado un objeto llamado obj:

  Dictionary<string, object> dicc = new Dictionary<string, object>();
foreach (PropertyDescriptor desc in TypeDescriptor.GetProperties(obj))
{
dicc.Add(desc.Name, desc.GetValue(obj));
}


Pero vamos a dar una vuelta de tuerca más. Partiendo del código anterior, es muy fácil crear un método de extensión sobre la clase object, de forma que podamos convertir en un diccionario cualquier objeto de nuestras aplicaciones, con toda la potencia y comodidad que nos aporta esta técnica.

El código sería:

  public static class Extensions
{
public static Dictionary<string, object> ToDictionary(this object obj)
{
Dictionary<string, object> dicc = new Dictionary<string, object>();
foreach (PropertyDescriptor desc in TypeDescriptor.GetProperties(obj))
{
dicc.Add(desc.Name, desc.GetValue(obj));
}
return dicc;
}
}


De esta forma, dispondremos de una potente forma de “diccionarizar” nuestras instancias, sean del tipo que sean, por ejemplo:


var juan = new { nombre = “Juan”, edad = 23 };
Dictionary<string, object> dicc = juan.ToDictionary();
Console.WriteLine(dicc[“nombre”]); // Escribe “Juan”

var dicc2 = “hola”.ToDictionary();
Console.WriteLine(dicc2[“Length”]); // Escribe 4


Espero que te sea de ayuda, Leo. ¡Y gracias por participar en Variable Not Found!

Publicado en: www.variablenotfound.com.

Referencias en cliente a tipos de servidor con ASP.NET Ajax

Cuestiones enviadas por lectoresHace unos días Pedro dejaba una consulta en los comentarios del post “Usando ASP.NET Ajax para el intercambio de entidades de datos” sobre un problema que le había surgido a la hora de referenciar desde script, en el lado cliente, una clase propia que utilizaba para intercambiar datos entre éste y el servidor.

En dicho post se mostraba la forma en que era posible intercambiar información estructurada con Ajax, definiendo en el servidor una clase propia y viendo cómo el ScriptManager, mágicamente, creaba un proxy (o espejo) en cliente que permitía su manipulación de forma muy cómoda y transparente al otro lado de la red.

De hecho, partíamos de una definición en el servidor así:

  public class Mensaje
{
public string Remitente;
public string Destinatario;
public DateTime Fecha;
public int Numero;
}


Y veíamos como desde cliente podíamos manipularla, en javascript, de la siguiente forma:

  msg = new Mensaje();
msg.Remitente = $get(“nombre”).value;
msg.Numero = 1;
msg.Destinatario = “servidor”;
msg.Fecha = new Date();


El problema que comentaba este lector es que, a diferencia del ejemplo, su entidad de datos se encontraba definida en un ensamblado y espacio de nombres diferente al del WebMethod que lo utilizaba, lo que provocaba la aparición de un error indicando que su clase no estaba definida.

Aunque al principio sospeché en que podía existir alguna limitación en la seriación JSON de los datos, después de indagar un poco dí con la solución. La lección que he aprendido es:


para usar desde cliente una clase generada de forma automática por el ScriptManager, es necesario referenciarla precedida del namespace en el que se encuentra definida

O en otras palabras, si la clase Mensaje está definida dentro del espacio de nombres A.B, la referencia en cliente deberá ser:

  var x = new A.B.Mensaje();

 ¿Y por qué funciona bien el ejemplo AjaxPingPong, si la referencia a la clase Mensaje no incluía su espacio de nombres? Pues debido a que estaba definida en el namespace por defecto del proyecto…

¡Gracias, Pedro, por participar en Variable Not Found!

Publicado en: www.variablenotfound.com.

Imágenes en cuadros de texto de formularios web

Cuestiones enviadas por lectoresRespondiendo a una consulta que hacía Joaquín hace un par de días, hoy describiremos una forma de hacer más atractivos los cuadros de edición de nuestros formularios web, introduciéndoles iconos o imágenes que, a la vez que adornan bastante, pueden ayudar al usuario a saber qué información debe introducir.

Pero para que quede claro lo que pretendemos, primero un ejemplo del resultado que vamos a conseguir:

Textboxes
 


La forma de conseguirlo es bastante sencilla. Basta con establecer, en las propiedades de estilo de los cuadros de edición una imagen de fondo con el icono que queremos incluir, y dejar un espaciado por la izquierda (padding-left) equivalente al ancho del mismo para que la introducción del texto comience a partir de ese punto.

Por ejemplo, si definimos las siguientes clases en el CSS de nuestra página (y suponiendo que la ruta de las imágenes sea correcta, claro):

 .lupa
{
background: white url(icono_lupa.gif) no-repeat 2px center;
padding: 2px 2px 2px 18px;
}
.telefono
{
background: white url(icono_telefono.gif) no-repeat 2px center;
padding: 2px 2px 2px 18px;
}


Como se puede observar, se establece un fondo blanco con una imagen cuya URL se especifica (icono_xxxx.gif), mostrada sin repetición (no-repeat), posicionada en coordenada horizontal 2px y centrada verticalmente. El padding izquierdo será de 18px para que comience ahí el área de edición, a la derecha de la imagen.

Podremos utilizar después en nuestro HTML un código como el siguiente para conseguir que los cuadros de edición apararezcan “adornados” como nos interese en cada momento eligiendo para cada uno de ellos la clase CSS apropiada:

 <input type=”text” class=”lupa” />
<input type=”text” class=”telefono” />


Espero que esto responda la duda, Joaquín.

Y por cierto, he utilizado esta técnica en el buscador del encabezado del blog, que lo tenía un poco soso…

Publicado en: www.variablenotfound.com.

Ocultar el texto de validadores en javascript (ASP.Net)

Pablo ha lanzado una pregunta en el post Deshabilitar y habilitar un validador ASP.Net desde Javascript publicado hace unos meses, que creo interesante responder en una entrada en exclusiva, por si puede ayudar a alguien más.

“Al utilizar la funcion ValidatorEnable para habilitar un validador, me activa automaticamente la validacion, y me muestra el texto que pongo para cuando la validacion no se cumpla, como puedo evitar esto”


Recordemos que el post trataba sobre cómo conseguir, desde Javascript, habilitar o deshabilitar validadores de controles incluidos en un webform utilizando la función ValidatorEnable(), que pone a nuestra disposición ASP.Net.

El problema, como comenta Pablo, es que al habilitar la validación desde script se muestran de forma automática los mensajes de error en todos aquellos controles que no sean válidos, provocando un efecto que puede resultar desconcertante para el usuario.

Indagando un poco, he comprobado que el problema se debe a que ValidatorEnable(), después de habilitar el validator, comprueba si los valores del control son correctos, mostrando el error en caso contrario.

Existen al menos dos formas de solucionar este problema.

La primera consiste en jugar con la visibilidad del mensaje de error. Como se observa en el siguiente código, al llamar a la función HabilitaValidador(), ésta llamará a ValidatorEnable y acto seguido, si el control no es válido, oculta el mensaje de error:


function HabilitaValidador(validator, habilitar)
{
ValidatorEnable(validator, habilitar);
if (habilitar && !validator.isvalid)
validator.style.visibility = “hidden”;
}

La segunda forma consiste en simular el comportamiento interno de ValidatorEnable, pero eliminando la llamada a la comprobación de la validez del control.

    function HabilitaValidador(validator, habilitar)
{
validator.enabled = habilitar;
}

Como se puede ver, simplemente se está estableciendo la propiedad enabled del validador, sin realizar ninguna comprobación posterior.

En ambos casos, la forma de utilizar esta función desde script sería la misma:


function activar()
{
HabilitaValidador(“<%= RequiredFieldValidator1.ClientID %>”, true);
}

Para mi gusto la opción más limpia, aunque sea jugando con la visibilidad de los elementos, es la primera de las mostradas, pues se respeta el ciclo completo de validación. En el segundo método nos estamos saltando las validaciones y el seguimiento de la validez global de la página, que la función original ValidatorEnable sí contempla.

Espero que esto resuelva la duda.

Publicado en: www.variablenotfound.com.