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

Maxlength en cuadros de texto de formularios MVC

ASP.NET MVC Resulta algo paradójico que ASP.NET MVC sea capaz de generar código para comprobar tanto en cliente como en servidor que la longitud del texto introducido sea menor que la indicada con la anotación [StringLength], y sin embargo, los helpers habituales no generen el atributo maxlength en el tag <input type="text">.

Podemos comprobarlo muy fácilmente. Por ejemplo, dada una entidad del Modelo como la siguiente:

public class Persona
{
  [StringLength(20, ErrorMessage="Máximo {1} caracteres")]
  public string Nombre { get; set; }
}
Si creamos su vista de edición por defecto e introducimos en ella los validadores en cliente, obtendremos en tiempo de ejecución un resultado como el que podemos apreciar en la siguiente captura de pantalla:
image

Es decir, los validadores automáticos, tanto en cliente como en servidor, nos avisan de que hemos superado el número máximo de caracteres a introducir, pero no se impide que esto se produzca mediante el atributo maxlength de la etiqueta el tag <input type="text">.

Afortunadamente hay varias formas de solucionar este pequeño inconveniente, como creando nuevos helpers o utilizando plantillas de edición personalizadas. En este post veremos cómo implementar la primera opción, creando un helper que realice la tarea de forma automática.

Html.LimitedTextBoxFor()

Vale, sé que no es un nombre estupendo para el helper, pero de momento va a tener que valer con ese ;-P. La idea es que podamos generar text boxes que limiten el número de caracteres permitidos en función de lo indicado en las anotaciones del Modelo. Es decir, sobre el ejemplo anterior, ocurriría lo siguiente:

// En la vista:
<%= Html.LimitedTextBoxFor(model => model.Nombre ) %>
 
// HTML resultante:
<input id="Nombre" maxlength="20" name="Nombre" type="text" value="" />

El código del helper es el siguiente, y lo comento brevemente justo a continuación:

public static MvcHtmlString LimitedTextBoxFor<TModel, TProperty>(
                this HtmlHelper<TModel> html, 
                Expression<Func<TModel, TProperty>> expression, 
                IDictionary<string, object> htmlAttributes)
{
  // Obtenemos los metadatos de la propiedad
  ModelMetadata metadata = 
         ModelMetadata.FromLambdaExpression(expression, html.ViewData);
 
  // Obtenemos la información utilizada para validar el tamaño del texto
  ControllerContext cctx = html.ViewContext.Controller.ControllerContext;
  StringLengthAttributeAdapter stringLengthValidator =
                    metadata.GetValidators(cctx)
                   .OfType<StringLengthAttributeAdapter>()
                   .FirstOrDefault();
 
  if (stringLengthValidator != null)
  {                                               // Si hay validación de este tipo...
    var parms = stringLengthValidator               
                     .GetClientValidationRules()     
                     .First()                        
                     .ValidationParameters;
                                                 // Obtenemos el valor del
    int maxlength = (int)parms["maximumLength"]; // tamaño máximo para el texto...
 
    if (htmlAttributes == null)
      htmlAttributes = new RouteValueDictionary();
 
    htmlAttributes.Add("maxlength", maxlength);  // y añadimos el atributo maxlength
  }
 
  return html.TextBoxFor(expression, htmlAttributes);
}

En primer lugar, estamos accediendo a los metadatos de la propiedad partiendo de la expresión lambda que recibimos como parámetro. Desde estos metadatos obtenemos, si existe, el validador asociado al atributo [StringLength], que es de tipo StringLengthAttributeAdapter.

Una vez obtenido el validador, buscamos en éste la información que será suministrada a los scripts en cliente, en particular el valor del parámetro “maximumLength”, introduciéndolo en la colección de atributos HTML que finalmente se envía al helper original asociando este valor al atributo maxlength de la etiqueta a generar.

Ahora, para simplificar las llamadas al helper desde las vistas, creamos un par de sobrecargas, similares a las que utilizamos normalmente en TextBoxFor():

public static MvcHtmlString LimitedTextBoxFor<TModel, TProperty>(
                  this HtmlHelper<TModel> html, 
                  Expression<Func<TModel, TProperty>> expression, 
                  object htmlAttributes)
{
  return html.LimitedTextBoxFor<TModel, TProperty>(
           expression, 
           ((IDictionary<string, object>)new RouteValueDictionary(htmlAttributes))
  );
}
 
public static MvcHtmlString LimitedTextBoxFor<TModel, TProperty>(
                  this HtmlHelper<TModel> html, 
                  Expression<Func<TModel, TProperty>> expression)
{
  return html.LimitedTextBoxFor(expression, null);
}

Y eso es todo. Si sustituimos en nuestras vistas las llamadas a TextBoxFor  por LimitedTextBoxFor tendremos la cuestión solucionada. Otra posibilidad, bastante más cómoda, sería retocar las plantillas de edición generadas por Visual Studio para que incluyan las llamadas a estos nuevos helpers.

Podéis encontrar el código fuente completo en Skydrive.

Publicado en: Variable not found.
Hey, ¿sabes que estoy en Twitter?

¿Esa enumeración está vacía?

¿Sómos los primeros en llegar al estadio? Casualmente encuentro en el post de Chris Eargle “Any() versus Count()” un tema del que pensaba escribir hace tiempo y al final dejé en el tintero: ¿cómo podemos determinar si una enumeración está vacía? Vale, es bien fácil, una enumeración está vacía si tiene cero elementos.

Si trabajamos con un array, podemos consultar la propiedad Length; si se trata de una colección, podemos utilizar la propiedad Count, que también nos devolverá el mismo dato de forma directa.

Sin embargo, cuando procesamos información es frecuente tratar con tipos de datos enumerables cuya implementación exacta desconocemos, y en los que no tenemos acceso a ninguna propiedad que nos permita conocer el número de elementos exactos que tiene almacenados. Por ejemplo, esto ocurre cuando obtenemos un conjunto de datos en forma de IEnumerable o trabajamos con LINQ sobre alguna fuente de información.

Pues bien, en estos casos hay que ser algo prudentes con la forma de consultar el número de elementos. Me he topado con código propio en el que, simplemente por despiste, utilizaba el método Count(), facilitado por LINQ para las enumeraciones y otras colecciones de datos, con objeto de saber si una lista estaba vacía:

var prods = services.GetProductsByCategory(category);
if (prods.Count() > 0)
{
   // Hacer algo con los elementos de la lista
}
else
{
   // No hay elementos
}

Seguro que ya os habréis percatado de que eso está mal, muy mal. El método Count() recorrerá uno por uno los elementos para contarlos, retornando el número exacto de ellos. En escenarios de un gran número de elementos, o cuando es costoso obtener cada elemento (como al traerlos de una base de datos) puede suponer un consumo de recursos enorme.

Y justo por esto existe el método Any(), que comprueba únicamente si existe al menos un elemento en la colección. Internamente este método itera sobre la colección retornando true cuando encuentra el primer elemento, por lo que es mucho más eficiente que el anterior:

var prods = services.GetProductsByCategory(category);
if (prods.Any()) // Mucho mejor 🙂
{
  // Hacer algo con los elementos de la lista
}
else
{
  // No hay elementos
}

La utilización de Any() también es interesante para comprobar la existencia de elementos que cumplan una condición, expresada en forma de predicado; retornará true cuando encuentre el primer elemento que lo haga cierto:

if (pedidos.Any(p => p.Pendiente))
{
   // Mostrar alerta, hay al menos un pedido pendiente

}

Estamos en la puerta de un Estadio y queremos saber si vamos a ser los primeros en entrar al recinto… ¿le preguntaríamos al portero el número exacto de aficionados que ya están dentro para, si es cero, saber que somos los primeros? ¿O nos bastaría simplemente con preguntarle si hay alguien? ;-P

Publicado en: Variable not found
Hey: ¡estoy en Twitter!

Cambios recomendables en el retorno de helpers en MVC 2

En la versión 1.0 de MVC, lo habitual era que los métodos helpers destinados a generar código de marcado retornaran un cadena de caracteres, como en el siguiente ejemplo:

public static class Helpers
{
  public static string Image(this HtmlHelper helper, string src, string alt)
  {
    TagBuilder tb = new TagBuilder("img");
    tb.Attributes["src"] = src;
    tb.Attributes["alt"] = alt;
    return tb.ToString(TagRenderMode.SelfClosing);
  } 
}

Que podía ser utilizado desde una vista de la siguiente forma, enviándolo al cliente con un bloque de salida directa de texto:

<%= Html.Image("/img/logo.gif", "Logo") %> 

Hasta aquí todo correcto. Ahora, ASP.NET 4 ha introducido un nuevo bloque de salida de texto capaz de codificar automáticamente en HTML, lo cual ayuda a evitar ataques relacionados con la inyección de scripts:

// Lo que antes (ASP.NET < 4) era...
<%= Html.Encode(Model.FirstName) %>
 
// En ASP.NET 4 es:
<%: Model.FirstName %>

El nuevo bloque de salida codificada es el método aconsejado para emitir contenido al cliente y se espera que los desarrolladores vayamos acostumbrándonos progresivamente a utilizarlo siempre, dejando a un lado al actual antiguo <%= %>.

Esto tiene un efecto lateral no deseado cuando estamos utilizando helpers que generen HTML. Por ejemplo, si emitimos la salida del helper anterior utilizando esta nueva técnica, observad el resultado que obtendremos:

// En la vista Index.aspx:
<%: Html.Image("/img/logo.gif", "Logo") %> 
image 

La solución a este problema se consigue utilizando como tipo de retorno del helper la nueva clase MvcHtmlString, introducida en ASP.NET MVC 2, que indica explícitamente a ASP.NET que no debe codificar la salida pues se trata de una cadena HTML controlada.

Así, modificando el código del helper de la siguiente forma, obtendremos el resultado esperado:

public static class Helpers
{
  public static MvcHtmlString Image(this HtmlHelper helper, string src, string alt)
  {
    TagBuilder tb = new TagBuilder("img");
    tb.Attributes["src"] = src;
    tb.Attributes["alt"] = alt;
    return MvcHtmlString.Create(tb.ToString(TagRenderMode.SelfClosing));
  } 
}

Todos los helpers del framework  MVC destinados a generar marcado retornan ahora, en la versión 2, este nuevo tipo de datos, y esto es lo mismo que deberíamos hacer con nuestros helpers personalizados. Además, gracias a unos curiosos malabarismos realizados en el interior de MvcHtmlString, nuestros helpers funcionarán tanto con ASP.NET 3.5 SP1 como con ASP.NET 4, tanto si utilizamos salida codificada como si no.

Publicado en: Variable not found.
Hey: ¡estoy en twitter!

Cuatro años desde que desapareció la variable

¡Cuatro años de variablenotfound.com!Mayo de 2006. Mucho ha llovido desde entonces (y sobre todo este año 😉). Windows XP era el rey del escritorio, y a pesar de sus inconvenientes, navegábamos con el hoy denostado Internet Explorer 6; Visual Studio 2005 había aparecido recientemente, y comenzábamos a crear aplicaciones para .NET 2.0… ¡ah, qué tiempos!

El pasado 8 de mayo volvimos a celebrar el aniversario de la publicación del primer post en Variable Not Found, ese blog que comenzó tímidamente hace ya cuatro años, con una declaración de intenciones como la siguiente:

Pretendo firmemente, y suelo ser bastante tenaz en mis propósitos, que este diario recoja todo aquello que me llame la atención y mis reflexiones relativas a la tecnología en general, y al mundo del desarrollo de software en particular.

Con mayor o menor frecuencia dependiendo del tiempo libre disponible en cada momento, desde esa fecha he ido publicando por aquí todo aquello que he considerado que podía interesar a alguien más que a un servidor, probablemente unas veces con más acierto que otras, pero, en cualquier caso, siempre con el mismo entusiasmo que el primer día.

Como en otras ocasiones, aprovecho para resumir los distintos periodos por los que hemos ido pasando desde aquél momento.

  • Año 1: la travesía del desierto (mayo 2006 – mayo 2007), caracterizado principalmente por ser yo el único visitante (poco más o menos) al blog, por aquellos tiempos disponible a través de la dirección jmaguilar.blogspot.com y con la imagen de una de las plantillas de Blogger.
    La siguiente gráfica muestra los primeros meses de vida del blog, donde era extraño superar las tres visitas al día. Esos picos que se ven probablemente sería yo mismo haciendo pruebas:
    image

    También es curioso los primeros veinte días sin datos: era tan ignorante que ni siquiera se me ocurrió activar ningún sistema de seguimiento hasta 20 días después de la inauguración oficial de la bitácora 😀

    Aprovecho para introducir un mensaje de aliento para los que estéis en esta situación ahora, empezando un blog: no os desaniméis, ni aun viendo este desastre: con un poco de esfuerzo todo puede cambiar. El desierto también tiene su fin.

  • Año 2: el despegue (mayo 2007 – mayo 2008), durante el cual se produjeron múltiples novedades, como la adquisición del dominio variablenotfound.com, la difusión de feeds a través de Feedburner, la creación del diseño actual, y la inclusión en agregadores y comunidades como Planeta Código, Planet WebDev y Geeks.ms.

    Este segundo año lo acabamos con un incremento del 2.500% en el número de visitas (la verdad, tampoco lo tenía muy difícil al partir casi de cero ;-)), debido en gran parte a algunas avalanchas procedentes de Menéame.

    Pero lo que me parecía más increíble era algo a lo que, curiosamente, no había prestado demasiada atención y que, sin embargo ahora, es uno de los parámetros que más valoro: los suscriptores a los feeds. Acabábamos el año con unos increíbles 380 suscriptores.
     

  • Año 3: la consolidación (mayo 2008 – mayo 2009), periodo sin grandes cambios en el que Variablenotfound.com continuó creciendo, aunque no de forma tan espectacular como lo había hecho anteriormente.

    Se incrementaron en un 75% el número de visitas procedentes de buscadores, debido a que comenzaba a notarse la antigüedad del blog, el número de referencias externas y su posicionamiento en buscadores, compensando así la práctica ausencia de meneos y otro tipo de avalancha.
    Según el inestable inestimable feedburner, los suscriptores a feeds superaron los 600, lo que suponía un aumento casi del 100% respecto al periodo anterior. Impresionante.

Estudiemos ahora en profundidad el año que acaba de finalizar:

Año 4: la variable social (mayo 2009-mayo 2010)

Durante este último año el número de visitantes ha continuado en la misma línea de estabilidad ya lograda en el periodo anterior, sin grandes sobresaltos. Los principales indicadores son:

  • Rozamos en total los cien mil usuarios únicos absolutos al año, sumando los visitantes a Variablenotfound.com y a su eco en geeks.ms,  Aunque no sea un número altísimo comparado con otros blogs, el carácter vertical y altamente especializado de mis publicaciones hacen que este número sea, en mi humilde opinión, espectacular.
  • Sigue aumentando el porcentaje de visitantes procedentes de Google buscadores; y esto a pesar de que la indexación no es especialmente buena… mmm, algún día tendré que mejorar eso.
  • En términos absolutos, la mayor parte de lectores se conectan desde España. Sin embargo, el mayor incremento se ha producido desde países como México, Argentina, Colombia, Perú o Chile.
  • El número de suscriptores a los feeds se acerca al millar… ¡simplemente impresionante! Estas dimensiones eran absolutamente impensables hace unos años, cuando pensaba que un blog con 500 lectores era una auténtica barbaridad, y ni en mis más optimistas previsiones era capaz de imaginar acercarme a este número.
  • Como curiosidad, el navegador más utilizado para acceder a los contenidos desde http://www.variablenotfound.com/ es Firefox (47%), frente a Internet Explorer (36%). A través del eco en geeks.ms es al contrario, un 46% Internet Explorer y no llega al 40% Firefox. Otro aspecto algo sorprendente es que el 70% de los lectores del blog todavía utiliza Windows XP.

El gran cambio introducido durante este periodo ha sido la inclusión de la componente social, tan al alza en estos tiempos. El pasado mes de octubre creé Variable not found en Facebook, que cuenta ya con más de cien amigos, y que esperaba sirviera como canal bidireccional de  comunicación con el otro lado. Aunque en la práctica todavía no ha sido así, y muy pocos miembros participan activamente, sí que es cierto que ofrece más canales para la distribución de contenidos y, seguro que algún día, para la comunicación entre nosotros.

En la actualidad utilizo Facebook para registrar enlaces a artículos que encuentro cada día y que me parecen interesantes. Relación Facebook/Twitter/BlogDe hecho, también los publico en el blog en las entradas categorizadas “Enlaces” de cada semana.

Profundizando en la misma línea, me he introducido de lleno en Twitter, que puedo decir que ha supuesto todo un descubrimiento. Aunque todavía soy sólo un aspirante a twitteador de los de verdad, estoy cada vez más integrado e identificado con esta nueva vía de comunicación inmediata. A día de hoy, sigo a 38 personas, y 58 followers escuchan mis gorjeos a diario, lo que me permite conversar con gente estupenda y plasmar impresiones y sensaciones en directo, a la vez que retransmitir por esa vía los enlaces que publico en Facebook.

Por otra parte, durante este último año he tenido ocasión de encontrar los primeros patrocinadores para el blog, lo cual, una vez descartado hacerme millonario con los ingresos de Adsense ;-), suponen al menos la posibilidad de sufragar gastos y darme un caprichillo de vez en cuando.

También, gracias a la difusión conseguida, he tenido el privilegio de probar algunos productos (como NDepend, o BaseKit) cedidos directamente por sus creadores, o acceder a información temprana de algunos sistemas (como el Vodafone Business Place) a través de invitaciones a eventos e información suministrada por los fabricantes.

Pero, como ya he dicho en otras ocasiones, el principal beneficio que sigo obteniendo es intangible. La motivación viene con cada post publicado, que brinda una nueva oportunidad de ampliar conocimientos y compartirlos con objeto de aportar un diminuto granito de arena a la comunidad de desarrolladores.

Y es que no hay mejor recompensa que el hecho de que estéis ahí: cada visita, cada suscriptor al feed, cada seguidor, cada comentario o contacto a través de cualquier vía hacen que continuar trabajando en este proyecto valga la pena.

Muchas gracias a todos, y espero que sigáis por aquí, ayudándome a buscar la variable.

Publicado en: Variable not found.

Validación de rangos decimales en cliente y servidor para ASP.NET MVC 2

 

ASP.NET MVCUna de las mejoras más esperadas de ASP.NET MVC 2 es, sin duda, el sistema integrado de validación del Modelo basado en las anotaciones de datos (Data Annotations). Y aunque la implementación en general es bastante apañada, hay algunos aspectos mejorables, sobre todo cuando intentamos desarrollar aplicaciones en nuestro idioma.

Por ejemplo, existe un curioso comportamiento del juego de herramientas de validación en cliente y servidor en lo relativo a la introducción de decimales en el Modelo. Imaginemos la siguiente entidad de datos, con sus correspondientes anotaciones:

public class Producto
{
  [Required(ErrorMessage="*")]
  public string Nombre { get; set; }
 
  [DisplayName("Peso (Kg.)")]
  [Range(0.1, 10, ErrorMessage="Entre {1} y {2}")]
  [Required(ErrorMessage="*")]
  public double Peso { get; set; }
}

Centrándonos en la propiedad Peso, la intención de sus anotaciones está bastante clara: queremos que sea de introducción obligatoria, y que su valor se encuentre en el rango entre 0,1 y 10 kilogramos.

Creamos ahora un formulario de introducción de datos para dicha entidad utilizando como base el generado por defecto por Visual Studio. El código resumido de la vista es el siguiente:

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
 
<script src="/Scripts/MicrosoftAjax.js" type="text/javascript"></script>
<script src="/Scripts/MicrosoftMvcValidation.js" type="text/javascript"></script>   
 
<h2>Create</h2>

<% Html.EnableClientValidation(); %>
 
<% using (Html.BeginForm()) {%>
 
... // Omitido
 
<% } %>
 
</asp:Content>

Si utilizamos exclusivamente la validación en servidor no habrá problema, pero si, como en el código anterior, activamos en ella la validación en cliente, podemos encontrarnos con un curioso y problemático escenario debido a la falta de sincronización entre las culturas en cliente y en servidor.

Sintomatología

Si en el campo Peso introducimos un entero, por ejemplo un “2”, todo funciona correctamente. El validador en cliente dejará pasar el valor, y en servidor se realizará la conversión de dicho valor a double sin problema.

Sin embargo, al intentar introducir un valor no entero como “1,23” comienza la fiesta. Si utilizamos como separador de decimales una coma, el validador en cliente no nos permitirá hacer un submit del formulario, quedándonos atrapados en esta capa:

Problema en cliente al validar un rango double

Si en cambio utilizamos como separador un punto, por ejemplo “2.5”, la validación en cliente considerará que el valor decimal es correcto, y permitirá el envío de los datos del formulario. Sin embargo, el servidor intentará obtener el valor double utilizando el formato asociado a la cultura actual, en la que el punto no es un carácter válido de separación, por lo que decidirá que el estado del Modelo es inválido, y nos enviará de vuelta al formulario:

Problema en servidor al validar un rango double

(Por cierto, hace unas semanas comenté por aquí cómo modificar los mensajes de validación por defecto en ASP.NET MVC 2, como el error mostrado en la captura anterior).

En resumen: no podemos continuar si utilizamos como separador decimal la coma (primer caso), ni tampoco si utilizamos el punto (segundo caso). Literalmente, estamos en un callejón sin salida.

Diagnóstico

El problema se debe básicamente a que los scripts de validación están utilizando únicamente la cultura “en-US”, en la que el carácter de separación decimal es el punto. Es decir, por defecto se utilizan los formatos de fecha y numéricos de la cultura inglesa/americana, y no existe ningún punto en el código de las librerías de scripting MicrosoftAjax o MicrosoftMvcValidation donde se modifiquen estos parámetros.

Sin embargo, el tratamiento en servidor se realiza bajo la cultura definida en el hilo de ejecución actual, en este caso la correspondiente a “es-ES”, en la que las comas son los separadores entre la parte entera y la decimal.

Esto es fácil de comprobar introduciendo al final de la vista:

<p>
  Cultura en servidor:
  <%= System.Threading.Thread.CurrentThread.CurrentCulture.Name %>
</p>
 
<script type="text/javascript">
  alert("Cultura en cliente: " + Sys.CultureInfo.CurrentCulture.name); 
</script>

 La cultura en cliente y servidor son diferentes

Tratamiento

Es posible que haya formas más sencillas para solucionar esta cuestión, pero de momento la única que he encontrado para sincronizar las culturas es forzar en el lado cliente la utilización de las opciones culturales que estén siendo consideradas en servidor.

Para ello, necesitamos asignar durante la inicialización de la página un objeto de tipo CultureInfo a la propiedad Sys.CultureInfo.CurrentCulture. Este objeto contiene los formatos numéricos y de fecha que serán utilizados en las operaciones de conversión llevadas a cabo desde las librerías de scripting Microsoft Ajax, y necesita dicha información durante su instanciación, como en el siguiente ejemplo:

<script type="text/javascript">
  var ci = {
      "name": "es-ES",
      "numberFormat":   {información de formato numérico}, 
      "dateTimeFormat": {información de formato de fecha y hora}
  };
  Sys.CultureInfo.CurrentCulture = Sys.CultureInfo._parse(ci);
</script>

Sin embargo, esto es algo más complejo de lo que podría parecer en un principio. El formato numérico contiene información sobre los separadores de millares, decimales, formas de representar negativos, monedas, dígitos, etc; de la misma forma, respecto a las fechas, es necesario suministrar el formato, nombre de meses, días de la semana, etc. Sin duda, un trabajo demasiado duro para tener que hacerlo a mano.

Por suerte, la representación de los formatos de números y fechas utilizado por las librerías de scripting de Microsoft son idénticas en cliente y servidor, por lo que podemos serializar como JSON los objetos Thread.CurrentThread.CurrentCulture.NumberFormat y Thread.CurrentThread.CurrentCulture.DateTimeFormat y utilizar el resultado para crear el objeto CultureInfo:

<%
  JavaScriptSerializer jss = new JavaScriptSerializer();
  var cultureInfo = Thread.CurrentThread.CurrentCulture;
  string name = cultureInfo.Name;
  string numberFormat = jss.Serialize(cultureInfo.NumberFormat);
  string dateFormat = jss.Serialize(cultureInfo.DateTimeFormat); 
%>
<script type="text/javascript">
  var ci = {
      "name": "<%= name %>",
      "numberFormat":  <%= numberFormat %>,
      "dateTimeFormat": <%= dateFormat %>
  };    
  Sys.CultureInfo.CurrentCulture = Sys.CultureInfo._parse(ci);
</script>

Pero está claro que no tiene demasiado sentido repetir el código anterior a lo largo y ancho de las vistas de edición de datos donde queramos activar la localización. Seguro que podemos mejorar esto… 😉

Medicina genérica: El helper Html.EnableLocalizedClientValidation()

Vamos a crear un helper que realice por nosotros estas tareas de la forma más sencilla posible.

Html.EnableLocalizedClientValidation() encapsula el comportamiento del helper estándar EnableClientValidation(), y añade los scripts de inicialización de las opciones culturales comentados anteriormente. Su uso será como se muestra a continuación:

<script src="../../Scripts/MicrosoftAjax.js" type="text/javascript"></script>
<script src="../../Scripts/MicrosoftMvcValidation.js" type="text/javascript"></script> 
<%= Html.EnableLocalizedClientValidation() %>
<h2>Create</h2>
<% using (Html.BeginForm()) { %>
// .. El resto del código de vista

La única diferencia respecto al método habitual es que estamos utilizando una expresión de salida <%= %>, y que el helper invocado es EnableLocalizedClientValidation().

El código del helper es:

using System.Text;
using System.Web.Script.Serialization;
using System.Threading;
 
namespace System.Web.Mvc
{
  public static class Extensions
  {
    public static MvcHtmlString EnableLocalizedClientValidation(this HtmlHelper html)
    {
      // Habilitamos la validación en cliente
      html.EnableClientValidation();
 
      // Obtenemos la información de la cultura actual
      JavaScriptSerializer jss = new JavaScriptSerializer();
      var cultureInfo = Thread.CurrentThread.CurrentCulture;
      string name = cultureInfo.Name;
      string numberFormat = jss.Serialize(cultureInfo.NumberFormat);
      string dateFormat = jss.Serialize(cultureInfo.DateTimeFormat);
 
      // Generamos el código
      StringBuilder sb = new StringBuilder();
      sb.Append("<script type="text/javascript">");
      sb.AppendLine("var ci = {");
      sb.AppendLine("    "name": "" + name + "",");
      sb.AppendLine("    "numberFormat": " + numberFormat + ", ");
      sb.AppendLine("    "dateTimeFormat": " + dateFormat);
      sb.AppendLine("};");
      sb.AppendLine("Sys.CultureInfo.CurrentCulture = Sys.CultureInfo._parse(ci);");
      sb.AppendLine("</script>");
      return MvcHtmlString.Create(sb.ToString());
    }
  }
}

Puedes descargar el código fuente desde mi SkyDrive.

Una última anotación: terminando de escribir este post, observo que el gran Phil Haack (PM de ASP.NET MVC) acaba de publicar una entrada comentando el mismo tema, y enfocando la solución desde otra óptica. Una lástima que no lo haya publicado antes, me habría ahorrado el tiempo que me ha llevado esta investigación, aunque, en cualquier caso, ha valido la pena para entender un poco más los entresijos del framework.

Publicado en: Variable not found
Hey, ¡estoy en twitter!

Introducing “Enlaces interesantes”, y cómo acceder al RSS/ATOM de Facebook desde .NET

Llevo ya algún tiempo utilizando la página de Variable Not Found en Facebook para publicar enlaces interesantes sobre desarrollo, ASP.NET, MVC y otros temas que voy encontrando por ahí. Normalmente anoto entradas en blogs, artículos o sitios webs a los que considero que vale la pena echar un vistazo en los ratos libres.

Integración Facebook-Twitter-BlogAdemás de en la página del blog en la red social, como por arte de magia, estos enlaces se difunden simultáneamente desde mi perfil personal de Facebook y a través de Twitter. Sin embargo, desde hace tiempo estaba estudiando la posibilidad de recopilar a su vez toda esta información para poder publicarla en el blog, cerrando completamente el círculo.

Aprovechando un huequito he creado una pequeña aplicación que toma esos enlaces y los maqueta de forma automática para mostrarlos en Variable not found. Así, a la vez que hago llegar estos enlaces a los suscriptores y lectores ocasionales del blog, los almaceno agrupados en una única ubicación sobre la que es posible realizar búsquedas, que es más cómodo que tomar rabos de pasas 😉

En un principio orienté la solución utilizando el SDK de Facebook (como introducción os recomiendo leer esta magnífica serie del amigo Eduard Tomás), pero estaba intentando matar mosquitos a cañonazos: demasiada complejidad para una necesidad tan simple.

Afortunadamente, me di cuenta de que esta información está disponible en formato ATOM y RSS, por lo que en principio puede ser consumida utilizando las clases de sindicación introducidas con .NET 3.5 en el espacio de nombres System.ServiceModel.Syndication del ensamblado System.ServiceModel.Web.

Por tanto, debería bastar con obtener las feeds, por ejemplo en formato ATOM, desde la dirección del feed http://www.facebook.com/feeds/page.php?format=atom10&id=94490426991, ¿no?

XmlException: Por razones de seguridad DTD está prohibido en este documento…

Pero claro, las cosas nunca son tan sencillas como se prevé en un principio. Utilizando contra los feeds de Facebook el código convencional para acceder a este tipo de información (y que de hecho funciona con muchos otros feeds), se lanzaba una excepción con un misterioso mensaje:

XmlReader reader = XmlReader.Create(feedURL);
SyndicationFeed feed = SyndicationFeed.Load(reader);
 
// Excepción XmlLException              ^^^^
//   "Por razones de seguridad DTD está prohibido en este documento XML. 
//    Para habilitar el procesamiento DTD establezca la propiedad ProhibitDtd 
//    en XmlReaderSettings como false y pásela al método XmlReader.Create."

Gracias a la inestimable colaboración del compañero Fiddler, pude averiguar que el problema se debía a que Facebook no estaba retornando la información en el formato solicitado (en este caso, ATOM), sino HTML:

Capturando tráfico con Fiddler

Si observáis, la petición inicial es redirigida a un nuevo recurso mediante un código de respuesta 302, una página web en cuyo título podemos observar el texto “Navegador incompatible”.

El motivo es que, obviamente, la petición realizada automáticamente por XmlReader para obtener los datos no incluye información sobre el navegador utilizado, Facebook detecta esta circunstancia y nos devuelve una página como la siguiente:

Estoy utilizando un navegador no compatible

Y esa es precisamente la causa de la excepción: los datos retornados no se encuentran en el formato esperado.

Para cambiar esto es necesario modificar ligeramente el código anterior, creando de forma manual la petición HTTP e inyectándole en el encabezado User-Agent un valor reconocible por los servidores de Facebook, como “Mozilla/4.0”, el empleado por IE8.

Para crear el objeto XmlReader utilizamos otra sobrecarga, de forma que le suministramos el Stream de respuesta de la conexión que hemos creado:

HttpWebRequest wr = (HttpWebRequest)WebRequest.Create(feedURL);
wr.UserAgent = "Mozilla/4.0";
 
XmlReader reader = XmlReader.Create(
   wr.GetResponse().GetResponseStream()
);
 
SyndicationFeed feed = SyndicationFeed.Load(reader);
foreach (var item in feed.Items)
{
   // Procesar entrada...

De esta forma, podemos acceder a feeds, incluso a los de Facebook, para obtener información y procesarla a nuestro antojo.

En el caso de mi megasuperaplicación, simplemente he tenido que parsear un poco el contenido y generar marcado HTML para cada entrada del feed con objeto de conseguir algo parecido a lo siguiente:

Aspecto de enlaces en Variable Not Found

El resultado lo podéis ver desde hace unas semanas en http://www.variablenotfound.com/search/label/enlaces.