El pasado día 29 de noviembre tuve el placer de dar una charla en el comité sobre JavaScript con el título “Javascript – Desde cero hacia las mejores prácticas”
Aquí os dejo los materiales de la charla por si os pueden resultar de interés.
Un saludo
Andoni Arroyo
El desarrollo de capa de presentación Web en .NET ha cambiado desde que Microsoft se decidió a realizar una implementación oficial del conocido patrón MVC en la plataforma ASP.NET y la (amplia) comunidad de desarrolladores de ASP.NET lo asumió con todos los cambios que implica.
Y esta implementación ha calado rápido y profundo, (ya se está desarrollando la segunda versión) ha llegado a la gente acostumbrada a Frameworks ligeros de desarrollo web que incluían sus propias implementaciones de MVC. Entre otras ventajas, ha ayudado a estandarizar la organización de los archivos del sitio y refinar las responsabilidades (Controladores -> Procesos de interfaz de usuario, workflow de la aplicación... Vistas –> mostrar la información de manera amigable y recoger los datos, validaciones de formato...).
Si deseamos acogernos a la implementación de Microsoft de dicho patrón deberemos ir encajando los problemas la funcionalidad de toda la vida sobre estas nuevas reglas de juego.
Uno de los requisitos clásicos más general es que nuestra aplicación disponga de características de globalización / localización. La idea general es la de siempre, evitar incluir ninguna referencia explicita a una determinada cultura y jugar con las características de globalización que nos ofrece el .NET Framework. Pero como ya sabemos, en Web todo se complica un poquito más. Al correr sobre un protocolo sin estado como HTTP recae sobre nuestra aplicación recordar la cultura especificada por el usuario entre las distintas peticiones.
Entonces tenemos clara la misión:
Suena fácil, no? Pues lo es, si somos un poco cuidadosos…
(Por cierto, os dejo al final del post el código de la solución para que os lo podáis descargar y probar.)
1 - Estableciendo las bases, recursos a los ficheros de recursos.
Vamos a ir realizando un ejemplo paso a paso para evitar perdernos:
Bueno, pues ya tenernos una aplicación que nos muestra los recursos en base a la cultura del Framework instalado (en el servidor Web en este caso) que se encarga de especificar la cultura del hilo de ejecución.
Ya es algo, pero no es lo que queremos, verdad?
(El que dude que revise la misión que hemos puesto arriba)
2- Estableciendo la cultura del hilo en ejecución
Ya sabemos que debemos establecer la cultura del hilo de ejecución para que el Framework cargue el fichero de recursos adecuado, pero ahora la pregunta es cuando?
Recordar que cada petición empieza de nuevo y no recuerda las anteriores ( HTTP es stateless). Indagando un poco en la MSDN podemos ver que la clase Controller (de la que derivan nuestros propios controllers) de la implementación del MVC de Microsoft especifica dos métodos virtuales que nos van a resultar muy interesantes:
Como debemos de establecer la cultura cada vez que nos realicen una llamada a cualquier action method de cualquier controlador, lo ideal es crear un controlador base del cual hereden todos los demás y sobrescribir en el método OnActionExecuting el mecanismo para restablecer la cultura. Nuestros controladores harán así transparente al resto de la aplicación las particularidades de trabajar con estado. También podríamos usar un atributo aplicado sobre la clase base y en la implementación del atributo especificar que implementa el interfaz IActionFilter si lo queremos hacer un poco mas AOP que OO.
En la implementación que os dejo utilizo un atributo con el que decoro la clase base (Al gusto!!)
En el ejemplo:
La clase base de los controladores:
[SetCulture]
public class BaseController : Controller
{
...
}
Y en la implementación de la clase del atributo programo como establecer la cultura seleccionada en el hilo activo:
public class SetCultureAttribute : FilterAttribute, IActionFilter
{
public void OnActionExecuting(ActionExecutingContext
actionContext)
{
CultureHelper.SetCulture(GetCurrentCulture
(actionContext), actionContext.
HttpContext.Session)
}
...
Para almacenar la cultura especificada entre las llamadas podemos emplear diferentes mecanismos, en este ejemplo el flujo de trabajo será el siguiente:
En la implementación que os dejo del proyecto podéis consultar los métodos que he creado para realizar dichas acciones, son muy sencillos y podéis modificarlos al gusto.
Los principales métodos son:
Aquí nos aparece otro problema.(Que raro, eh?)
Si el usuario es la primera vez que accede a la Web no tiene cookie ni session establecida.
Para intentar que la aplicación sea lo más “inteligente” posible, recogemos del navegador las culturas que tiene especificadas y las cruzamos con una sección especifica del fichero de configuración creada a tal efecto.
Por ejemplo, si el usuario tiene Chino e italiano necesito determinar si mi aplicación dispone un algún fichero de recursos que da soporte a alguno de los mismos. Para ello me creo una section en el fichero de configuración y un handler que lo soporte que especifique una lista de culturas soportadas y su orden de aplicación. (Así vemos también como poder realizar esta tarea.)
Observar que la tarea no es tan sencilla como coger el idioma y asignarlo al hilo y dejar que el Framework resuelva. (si no lo puede resolver que aplique la predeterminada) puesto que si el usuario tiene, entre todos los lenguajes del navegador, uno que tenemos implementado nos lo estaríamos saltando. (Por ejemplo Chino, Italiano, Español, Ruso)
En el fichero de configuración especificamos:
<configSections>
...
<section name="EnabledLanguages" type="AndoniArroyo.MLTest.
Controllers.Infrastructure.Configuration.EnabledLanguagesSection,
AndoniArroyo.MLTest"/>
</configSections>
...
además incuimos la citada sección:
<!--Especifica el conjunto de culturas con el que trabaja la aplicación. La última es la cultura por defecto-->
<EnabledLanguages>
<Languages>
<add title="Spanish" code="es-ES" />
<add title="English" code="en-GB" />
</Languages>
</EnabledLanguages>
Para que la aplicación pueda manejar esta section debemos implementar el handler que la maneje:
namespace AndoniArroyo.MLTest.Controllers.Infrastructure.
Configuration
{
public sealed class EnabledLanguagesSection : ConfigurationSection
{
[ConfigurationProperty("Languages", IsDefaultCollection = true,
IsRequired = true)]
internal LanguageElementCollection EnabledLanguages
{
get { return (LanguageElementCollection)this["Languages"]; }
}
}
}
Estos lenguajes será los que tendrá en cuenta el método que intenta cargar el lenguaje desde la información recogida del navegador.
Pues ya casi lo tenemos.
Nos queda por ver como el usuario puede explicitamente modificar la cultura con la que desea trabajar en la aplicación. Visto todos lo anterior la cosa es fácil, no? Basta con crear un action method de modificación de la cultura y en la implementación del mismo llamar explícitamente al método de establecer cultura con el parámetro recibido. (CultureHelper.SetCulture pasándole la cultura especificada por el usuario y la referencia al objeto de sesión...)
Recapitulando, hemos visto unas cuantas cosas:
Y como extra lo prometido el ejemplo con todas estas ideas en acción.
Ha sido liberada la versión 3.0 (como yo que también soy 3.0!! ) del navegador Firefox. Vaya por delante que soy usuario convencido del mismo y el producto destaca por su calidad y rendimiento.
Ahora, otra cosa es la tabla de comparaciones del sitio web oficial, atentos que no tiene desperdicio:
Madre mia que publicidad barata y ofensiva. Con lo facil que es dejar que la gente pruebe lo bueno que es y se decida. Mal, mal...
Un saludo.
