Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

19 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
lunes, 25 de abril de 2011
Microsoft Web CampsVaya, tenía programado este post para que fuera publicado automáticamente hace unos días, pero algo habré hecho mal y se ha quedado en la recámara… bueno, pues más vale tarde que nunca O:-)

Como sabréis, hace poco ha finalizado la gira “Make Web Not War”, una serie de eventos organizados por Microsoft en cinco ciudades del país en los que se trataban distintos temas relacionados con el desarrollo para la web, y donde he tenido la oportunidad de participar como ponente, hablando sobre la última versión del framework ASP.NET MVC.

Aunque me ha tenido varias semanas fuera de juego laboral y blogosféricamente hablando (y lo que todavía tardaré en recuperar la normalidad…), he de decir que ha sido un experiencia realmente impresionante, de la que salgo con muy gratos recuerdos y un buen puñado de amigos con los que espero volver a coincidir en posteriores ocasiones.

A lo que iba, unos días atrás se han publicado los materiales y los vídeos de todas las ponencias del evento de Madrid, la última ciudad de la gira, y a los que podéis acceder desde los siguientes enlaces. En general, se trata de contenidos muy atractivos para los que trabajamos con la web, y seguro que vale la pena dedicar una tarde a que fenómenos como Martín, Jorge, Boris, Alex o Rafael nos cuenten cosas interesantes. Bueno, y si queréis conocer algo de MVC 3, pues también ;-)
Estándares web W3CEstándares Web W3C
Martín Álvarez-Espinar (W3C)

Descargar presentación
Ver vídeo
Migrar a HTML 5 es fácil... si sabes cómoMigrar a HTML 5 es fácil… si sabes cómo
Jorge Casar (Frontend Spain)

Descargar presentación
Ver vídeo
IE9 para desarrolladores webIE9 para desarrolladores web
Boris Armenta (Microsoft)

Descargar presentación
Ver vídeo
Una web más interoperableUna web más interoperable
Alejandro Hidalgo (Plain Concepts)

Descargar presentación 
Ver vídeo
El poder de los CMSEl poder de los CMS
Rafael Gerardo (Vector SF)

Descargar presentación
Ver vídeo
Presentación MVC 3ASP.NET MVC3
José María Aguilar

Descargar presentación 
Ver vídeo
Y por último, aprovechar para agradecer a la organización, a los chicos del equipo de evangelistas de Microsoft, y al resto de ponentes (inclusive Iván y Ángel, que no estuvieron en Madrid pero sí en otras ciudades) la confianza depositada y los buenos ratos que hemos pasado, paellas y chuletones de la tierra incluidos ;-)

Publicado en: Variable not found.
domingo, 24 de abril de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el lunes, 11 de abril de 2011 hasta el domingo, 24 de abril de 2011. Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found
martes, 12 de abril de 2011
ASP.NET MVCYa me parecía que el equipo de MVC llevaba mucho tiempo en silencio ;-). Acaba de publicarse una actualización para las herramientas de ASP.NET MVC 3 en la que se incluyen algunas novedades interesantes,  y a las que ya he podido echar un vistazo. Os comento lo que he encontrado de momento en ellas.

Novedades a primera vista

El primer pequeño cambio que notamos al instalar esta actualización, es que algunos de los cuadros de diálogo y nombres de plantillas que antes aparecían en español ahora aparecen de nuevo en inglés, como antes de instalar el paquete de idioma correspondiente. La plantilla de aplicaciones MVC 3 vuelve a llamarse “MVC 3 Web Application”, y los cuadros de diálogo vuelven su idioma original. Pero bueno, nada grave.

Nuevo cuadro de diálogo "Crear proyecto"

Justo a continuación, ya creando el primer proyecto MVC 3, vemos que en el cuadro de diálogo inicial ha sido introducida una nueva plantilla llamada “Intranet Application”, y aparece un checkbox “use HTML5 semantic markup”.

El uso de esta nueva plantilla generará un proyecto prácticamente idéntico al habitualmente creado utilizando la plantilla “Aplicación de internet”, pero en lugar de utilizar el sistema de membresía de ASP.NET, utilizará autenticación Windows. Por tanto, ni rastro de controlador Account, ni de su Modelo, ni sus vistas; sólo encontraremos instrucciones para activar en IIS 7 e IIS Express este modelo de seguridad.

Por otra parte, marcando el nuevo checkbox podemos hacer que las vistas sean generadas utilizando marcado semántico HTML5. En la práctica, esto sólo implica que en el marcado del Layout encontraremos tags como HEADER, NAV, SECTION, o FOOTER.

Más scripts, y más actualizados

Si nos quejamos de la velocidad de los chicos de MVC a la hora de sacar releases, los de jQuery no se quedan nada atrás… incluso diría que los superan. Por ejemplo, la plantilla de ASP.NET MVC 3 incluía por defecto jQuery 1.4.4, y recientemente ha aparecido la 1.5.2… en tres meses, han aparecido al menos 4 revisiones.

Actualización de jQuery vía NugetLos nuevos proyectos ASP.NET MVC vienen ya de serie con la versión 1.5.1, pero lo que es más interesante, es que ésta se incorpora en el proyecto como un paquete predescargado de Nuget.  Por tanto, nada más abrir el proyecto recién creado, o en cualquier momento a partir de entonces, podemos utilizar Nuget para obtener las actualizaciones del mismo.

Lo mismo ocurre con jquery.Validation y con jQuery.UI. En ambos casos se ha incluido la versión 1.8, y de la misma forma, pueden ser actualizados a través de Nuget.

Eso sí, un detalle a tener en cuenta es que la inclusión de jquery desde nuestro código (el <script src..> que solemos encontrar en nuestro Layout o en algunas vistas) debemos modificarla de forma manual, puesto que el nombre de archivo incluye la versión específica, y Nuget no lo actualizará por nosotros.

Otra novedad al respecto es que se incluye de serie la biblioteca Modernizr, una interesante herramienta que nos facilita la detección de características de browsers, permitiéndonos el uso de tecnologías modernas como HTML5 o CSS3, mientras mantenemos la compatibilidad con navegadores anteriores.

Más andamiaje

El cuadro de diálogo de añadir controladores ha sido potenciado considerablemente. En este diálogo, hasta ahora sólo indicábamos el nombre del controlador y si queríamos generar código de acciones para las operaciones CRUD.

Ahora, tras instalar esta actualización, tendremos a nuestra disposición una herramienta mucho más potente y compleja, que nos permite crear controladores, vistas, e incluso clases de contexto de datos para Entity Framework 4.1 (que se instala de serie en nuestros proyectos) con métodos básicos de acceso a datos.

Nuevo cuadro de diálogo para añadir controladores
Disponemos de tres opciones para crear un controlador: vacío, con acciones de edición vacías, y con vistas de lectura y edición usando Entity Framework.

Las dos primeras son equivalentes a lo que podíamos conseguir anteriormente, un controlador únicamente con la acción Index(), o con las acciones habituales CRUD, pero sin demasiado código en su interior.

La tercera opción, sin embargo, supone un gran avance respecto a las demás, puesto que permite, de un plumazo, generar todo el código que necesitamos para cubrir los habituales escenarios CRUD (consulta, altas, bajas, modificaciones y eliminación) basándose en el nuevo Entity Framework 4.1, que por cierto también acaba de salir del horno.

Obviamente, como es habitual, tendremos que retocar el código generado, pero como base no está nada mal la cantidad de trabajo que nos ahorra.

Por ejemplo, supongamos que creamos un proyecto MVC 3 vacío y añadimos a la carpeta Models una clase como la siguiente:

    public class Persona
    {
        [Key]
        public int IdPersona { get; set; }
 
        [Required]
        [StringLength(50)]
        public string Nombre { get; set; }
 
        [Required]
        [StringLength(50)]
        public string Apellidos { get; set; }
 
        public DateTime FechaNacimiento { get; set; }
    }

Como siempre, seleccionando la opción “Añadir controlador” sobre la carpeta Controllers del proyecto, podemos generar una clase controlador así:

Añadir controlador

Observad el desplegable donde se nos solicita la clase del contexto de datos. En ella podemos seleccionar el contexto de objetos (si usamos los tradicionales db-first o model-first de EF 4) o contexto de datos (usando code-first), desde donde se obtendrá la información. Además, si no existe, podemos incluso generar esta clase (para code-first) de forma automática desde este mismo punto.

A continuación, pulsando “Add”, se habrán generado automáticamente los siguientes elementos:

  • la clase PersonasController, dentro de la carpeta correspondiente, en cuyo interior encontraremos la implementación completa de las acciones Index, Details, Create, Edit y Delete,
  • vistas para cada una de las acciones anteriores, que tienen en cuenta algunas características definidas en el modelo de datos, como las anotaciones o relaciones entre entidades.
De hecho, el código generado es totalmente funcional. Si directamente ejecutamos la solución, gracias a la magia del code-first, tendremos funcionando un mantenimiento completo de la entidad Persona, sin ni siquiera necesidad de crear la base de datos de forma manual:

Mantenimiento generado

Bueno, y esto es todo de momento. Ya conforme vaya descubriendo más novedades o particularidades las iremos viendo por aquí.

Aquí tenéis el enlace para descargar la actualización de herramientas para MVC 3; en el mismo sitio encontraréis las notas de revisión, que describen los cambios introducidos.

Publicado en: Variable not found.
La ruta por defecto de ASP.NET MVC es válida para la gran mayoría de escenarios simples, permitiéndonos acceder a las acciones a través de URLs del tipo
http://{servidor:puerto}/{controlador}/{accion}
Así, dada una clase controlador con acciones como las siguientes:

public class InformacionCorporativaController : Controller
{
    public ActionResult QuienesSomos()
    {
        return View();
    }
    public ActionResult MisionVisionYValores()
    {
        return View();
    }
    public ActionResult UneteANuestroEquipo()
    {
        return View();
    }
}

… podríamos acceder a ellas utilizando direcciones tan naturales como /InformacionCorporativa/QuienesSomos, o /InformacionCorporativa/MisionVisionYValores. Sin duda, un gran avance vistas a ofrecer a nuestros usuarios un esquema de rutas limpio, intuitivo, y de paso, mejorar nuestro posicionamiento.

Sin embargo, ¿no os parece que sería mejor aún poder acceder a acciones y controladores utilizando guiones para separar los distintos términos? Me refiero a poder utilizar, por ejemplo, la URL /Informacion-corporativa/Quienes-Somos, o /Informacion-corporativa/Unete-a-nuestro-equipo.

Obviamente no podemos modificar el nombre de nuestros controladores y acciones, puesto que nuestros lenguajes de programación no permiten el uso de guiones en el nombre de los identificadores.

Ante este escenario, una posibilidad sería asignar mediante el atributo [ActionName] un nombre alternativo a cada una de estas acciones. Sin embargo, además del trabajo que esto implica, no habría una forma sencilla de conseguirlo también para los nombres de las clases controlador. Otra opción sería registrar en la tabla de rutas una entrada específica para cada una de las acciones. Aunque no tiene contraindicaciones y cubriría perfectamente nuestras necesidades, uuffff… sin duda es demasiado trabajo a estas alturas.

Afortunadamente, existen en el framework bastantes puntos de extensión donde podemos “enganchar” nuestra propia lógica al proceso de las peticiones, y emplearlos para conseguir solucionar de forma global problemas como este. Y uno de ellos es el sistema de routing.

1. ¡Convenciones al poder!

A continuación vamos a ver cómo conseguirlo de forma global utilizando el sistema de routing, y basándonos en una convención muy simple que vamos a establecer: los identificadores de controladores y acciones que contengan un guión bajo (“_”) serán convertidos a nivel de rutas en guiones.

Dado que el guión bajo es perfectamente válido en los nombre de clases y métodos, sólo tendremos que introducir en ellos este carácter en el lugar donde queremos que aparezcan los guiones, y dejar que el sistema de rutado se encargue de realizar la transformación de forma automática. Y, por supuesto, realizaremos esta transformación en sentido bidireccional, es decir, tanto cuando se analiza la URL para determinar el controlador y acción a ejecutar, como cuando se genera la dirección a partir de los parámetros de ruta.

2. La clase FriendlyRoute

A continuación, vamos a crear una nueva clase, a la que llamaremos FriendlyRoute, y que dotaremos de la lógica de transformación de guiones medios en guiones bajos, y viceversa. Nada que no podamos resolver en una escasa veintena de líneas de código:
public class FriendlyRoute : Route
{
    public FriendlyRoute(string url, object defaults) :
        base(url, new RouteValueDictionary(defaults), new MvcRouteHandler()) { }
 
    public override RouteData GetRouteData(HttpContextBase httpContext)
    {
        var routeData = base.GetRouteData(httpContext);
        RouteValueDictionary values = routeData.Values;
        values["controller"] = (values["controller"] as string).Replace("-", "_");
        values["action"] = (values["action"] as string).Replace("-", "_");
        return routeData;
    }
 
    public override VirtualPathData GetVirtualPath(RequestContext ctx, RouteValueDictionary values)
    {
        values["controller"] = (values["controller"] as string).Replace("_", "-").ToLower();
        values["action"] = (values["action"] as string).Replace("_", "-").ToLower();
        return base.GetVirtualPath(ctx, values);
    }
}

Del código anterior, destacar algunos aspectos:
  • sólo he creado un constructor, he de decirlo, por pura pereza. En realidad, si quisiéramos cubrir más casuística, como la introducción de restricciones o de espacios de nombre que sí permiten las distintas sobrecargas de la clase Route, deberíamos crear todas ellas para nuestra clase. Pero vaya, es trivial en cualquier caso.
  • el método GetRouteData() es utilizado por el framework para obtener los datos de ruta de una petición entrante. Como puede observarse en el código anterior, simplemente ejecutamos la lógica de la clase base, y aplicamos las oportunas transformaciones (de guiones medios a bajos).
  • el método GetVirtualPath() es utilizado para la transformación inversa, es decir, para generar una URL partiendo de valores de los parámetros de ruta. En este caso, primero retocamos ligeramente los valores del nombre de controlador y acción, transformando los guiones bajos en medios y pasándolos a minúsculas, y posteriormente invocamos a la lógica de la clase base para que genere la URL por nosotros.
A partir de este momento ya podríamos añadir en la tabla de rutas objetos de esta clase con un código como el siguiente:
routes.Add("default", 
    new FriendlyRoute(
        "{controller}/{action}/{id}", // URL con parámetros
        new { controller = "inicio", action = "portada_principal", id = UrlParameter.Optional }
    )
);

Observad que una de las ventajas de utilizar esta técnica es que a nivel de código utilizaremos siempre el nombre real de los controladores y acciones (con el guión bajo), es el routing el que realizará las transformaciones. Esto, entre otros beneficios, nos permite seguir utilizando el imprescindible T4MVC para evitar las “magic strings” en nuestro código.

3. Pero es queeee… yo estoy acostumbrado a usar routes.MapRoute()… O:-)

No pasa nada, también podemos ponértelo así de fácil. Los métodos MapRoute() que solemos usar en el método RegisterRoutes del global.asax no son más que extensores de la clase RouteCollection, por lo que podemos basarnos en esta misma idea y crear extensiones personalizadas que nos pongan más a mano el mapeo de nuestras amigables rutas:
public static class RouteCollectionExtensions
{
    public static Route MapFriendlyRoute(this RouteCollection routes, string name, string url, object defaults)
    {
        var route = new FriendlyRoute(url, defaults);
        routes.Add(name, route);
        return route;
    }
}

De esta forma, ahora bastaría con referenciar desde el global.asax el espacio de nombres donde hemos definido la clase anterior y ya podemos llenar la tabla de rutas utilizando sentencias como la siguiente:
routes.MapFriendlyRoute(
    "Default",                    // Nombre de ruta
    "{controller}/{action}/{id}", // URL con parámetros
    new { controller = "inicio", action = "portada_principal", id = UrlParameter.Optional } 
);

Así, una vez introducida la ruta anterior en lugar de la que viene por defecto en proyectos ASP.NET MVC, ya nuestro sistema podrá recibir una petición como GET /Nombre-Controlador/Nombre-Accion y mapearla hacia a la acción Nombre_Accion de la clase controlador Nombre_ControladorController.

Por si os interesa, he dejado código y demo en SkyDrive.


Friendly Route Demo


Publicado en: Variable not found.
domingo, 10 de abril de 2011
Bien, pues tras el parón de la gira Make Web Not War, volvemos a la carga con los enlaces que he ido recopilando durante este tiempo en Variable not found en Facebook y Twitter.
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found
lunes, 21 de marzo de 2011
Web Camps 2011: Make Web, not WarDurante las próximas semanas estaré de gira participando como ponente en los Web Camps que se celebrarán en cinco ciudades del país, bajo el lema “Make Web Not War”.

En estos eventos, como se puede ver en la agenda, se tratarán temas relacionados con tecnologías y desarrollo para la web:
  • Migración a HTML5
  • IE9 para desarrolladores
  • Buenas prácticas en la detección de navegadores
  • El poder de los CMS
  • ASP.NET MVC 3
El itinerario previsto es:
  • Barcelona, 22 de marzo
  • Valencia, 24 de marzo
  • Bilbao, 29 de marzo
  • Sevilla, 31 de marzo (hey, juego en casa! ;-))
  • Madrid, 5 de abril
Si estáis interesados en asistir, sólo tenéis que ir a la web oficial de la gira, e inscribiros en la ciudad más cercana. En la misma página encontraréis información sobre los horarios y ubicación exacta del evento.

¡Espero veros por allí! :-)

Publicado en: Variable not found.
domingo, 20 de marzo de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el lunes, 14 de marzo de 2011 hasta el domingo, 20 de marzo de 2011. Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: www.variablenotfound.com.
martes, 15 de marzo de 2011
ASP.NET MVCComo sabemos, en MVC 2 y MVC 3 el atributo [DisplayName] nos permite especificar en cada propiedad de las entidades del Modelo un nombre descriptivo que, entre otras cosas, es utilizado como etiqueta en formularios si empleamos el helper Html.LabelFor().

Así, dada una clase del Modelo como la siguiente:
public class Persona
{
    [DisplayName("Nombre completo")]
    public string Name { get; set; }
 
    [DisplayName("Edad actual")]
    public int Age { get; set; }
}
si implementamos una vista de edición sobre ella similar a la mostrada a continuación, vemos el resultado que obtendríamos en tiempo de ejecución:

Vista de edición y resultado en tiempo de ejecución
Este mecanismo resulta muy cómodo y útil la mayoría de las veces, sin embargo, cuando estamos desarrollando sitios multiidioma, rápidamente vamos a encontrarnos con que este enfoque no es suficiente, puesto que asocia una única descripción textual a la propiedad independientemente de la cultura activa.

A diferencia de otros atributos como las anotaciones de validación, DisplayName no incorpora ninguna forma para indicar una referencia hacia el recurso localizado, es decir, identificar el tipo (la clase) que representa al archivo de recursos (.resx) donde se encuentra la traducción del término, así como la propiedad o clave en la que lo encontraremos. Por ejemplo, el data annotation [Required] permite hacerlo de la siguiente forma:
[Required(
    ErrorMessageResourceName="NombreObligatorio", 
    ErrorMessageResourceType=typeof(Resources.Textos)
)]
public string Name { get; set; }
Ahora bastaría con crear la carpeta App_GlobalResources un archivo de recursos llamado “Textos.resx” (obviamente el nombre puede ser cualquiera, siempre que coincida con el referenciado en el parámetro ErrorMessageResourceType anterior), e introducir en él la clave “NombreObligatorio” con su correspondiente valor. Para añadir la traducción al inglés, bastaría con hacer lo mismo sobre el archivo Textos.en.resx, y así sucesivamente.

Archivos de recursos

Afortunadamente, a partir de ASP.NET MVC 3 podemos utilizar la anotación Display, disponible en System.ComponentModel.DataAnnotations a partir de la versión 4 del framework, de la siguiente forma:
[Display(Name="Nombre", ResourceType=typeof(Resources.Textos))]
public string Name { get; set; }
Como podréis intuir, el parámetro Name indica la clave del recurso incluido en la clase especificada en ResourceType.

Sin embargo, el uso de este atributo requiere que los elementos del archivo de recursos sean de acceso público, y no interno, como son por defecto cuando creamos los .resx en App_GlobalResources. Si no tenemos en cuenta este aspecto, podemos encontrarnos con un error como el siguiente:

Cannot retrieve property 'Name' because localization failed.  Type 'Resources.Textos' is not public or does not contain a public static string property with the name 'Nombre'.

Ante este error, tenemos varias fórmulas para conseguir acceso a los recursos localizados:
  • la primera de ellos a lo bestia, accediendo a la clase generada desde el archivo de recursos (por ejemplo Textos.Designer.cs) y cambiando los modificadores de la clase y sus miembros de “internal” a “public”. Obviamente, este cambio sólo nos vale hasta que se vuelva a generar el código , cosa que ocurrirá al modificar o añadir nuevas cadenas de texto, por lo que no es nada recomendable.
  • otra, sacar los recursos de la carpeta App_GlobalResources y moverlos a cualquier otra carpeta del proyecto (por ejemplo, /Recursos). Tras ello, en las propiedades del archivo .resx podemos modificar la “Herramienta personalizada” y establecerla a “PublicResXFileCodeGenerator” para asegurar su acceso público.
  • una última sería crear ensamblados satélite, lo cual requiere la añadir un nuevo proyecto de biblioteca de clases en la solución, en el que introduciremos exclusivamente los archivos de recursos localizados.
Pero si ninguna de ellas nos convence, o bien estamos todavía trabajando con MVC 2 y .NET 3.5SP1, todavía tenemos otra posibilidad:

[LocalizedDisplayNameAtribute]

Es realmente sencillo implementar un atributo que nos permita conseguir algo parecido a lo descrito anteriormente. Simplemente heredando de DisplayNameAttribute y sobrescribiendo su propiedad DisplayName podemos hacer que su valor sea tomado desde los recursos de la aplicación:
public class LocalizedDisplayNameAttribute : DisplayNameAttribute
{
    private readonly string _resourceName;
    public LocalizedDisplayNameAttribute(string resourceName)
    {
        _resourceName = resourceName;
    }
 
    public override string DisplayName
    {
        get { return Resources.Textos.ResourceManager.GetString(_resourceName); }
    }
}
Archivos de recursosObservad que para simplificar la sintaxis de uso y su implementación, estamos asumiendo que los recursos se encuentran en Resources.Textos, la clase generada automáticamente a partir del archivo Textos.resx.

De esta forma, ahora decoraremos las propiedades del modelo no con el texto que queremos que aparezca en pantalla, sino con la clave del recurso, y dado que la clase de recursos está definida en el atributo, no será necesario indicarla:
public class Persona
{
    [LocalizedDisplayName("Nombre")]
    public string Name { get; set; }
 
    [LocalizedDisplayName("Edad")]
    public int Age { get; set; }
}
Y por si os resulta de interés, he dejado un proyecto de demostración de este atributo en Skydrive.

Publicado en: Variable not found.
domingo, 13 de marzo de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el lunes, 07 de marzo de 2011 hasta el domingo, 13 de marzo de 2011.

Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found
miércoles, 9 de marzo de 2011
Hace muchos, pero muchos, años ya comenté por aquí un buen ejemplo de lo que ocurre cuando un desarrollador diseña el interfaz de usuario de una aplicación. También, ya más recientemente, profundizaba en este curioso tema en el post titulado Indicios de que tu interfaz de usuario fue creado por un programador.

Esta semana he vuelto a encontrar un ejemplo, creo que bastante ilustrativo, del fenómeno. La captura de pantalla pertenece a la herramienta gratuita Bulk Rename Utility, una utilidad imprescindible cuando necesitamos renombrar de forma masiva archivos en un directorio.

Bulk rename utility
Funcionalmente, ninguna pega, más bien todo lo contrario: es potentísima, e incluso una vez la has utilizado un poco resulta hasta fácil de manejar.

Ahora bien, a nivel de interfaz la primera impresión es una auténtica agresión al usuario. De hecho, hasta los propios autores se lo toman con filosofía, como podemos leer en el primer párrafo del tutorial de su web:
“You've installed the software, you've launched it, and you now see a million and one controls and boxes on the screen. The first thing to do is DO NOT PANIC!”
Pero vaya, como ya decía años atrás, el que esté libre de pecado que tire la primera piedra ;-)

Publicado en: Variable not found.
martes, 8 de marzo de 2011
Explorer-Firefox-ChromeYoy a comentar un problema que llevaba arrastrando meses, y que es realmente sencillo de solucionar. En este caso, se trata de un inconveniente muy molesto que encontramos cuando estamos depurando sitios web desde Visual Studio utilizando el servidor integrado (Cassini), en Windows 7.

Resulta que si utilizamos Internet Explorer en cualquiera de sus versiones todo funciona correctamente y a toda velocidad, pero la carga de páginas, imágenes y scripts en local se eterniza si estamos utilizando Firefox o Google Chrome.

Al parecer, en ambos casos se trata de un problema con la resolución de nombres del equipo en IPv6, que no es capaz de traducir de forma eficiente el nombre localhost. En Firefox se puede arreglar a nivel de aplicación, pero si queremos que todo vaya bien en Chrome habrá que modificar la configuración global del equipo.

about:configSolución en Firefox

Si sólo queremos corregir este problema en Firefox, debemos abrir la aplicación y teclear en su barra de direcciones “about:config”. Tras ello, lo primero será confirmar nuestra decisión de acceder a la configuración de la aplicación en la pantalla donde se nos informa de los mil y un peligros a los que nos exponemos al hacerlo.

A continuación en el filtro teclead “ipv6”, lo que provocará que en la lista de parámetros del sistema se quede únicamente el que nos permitirá desactivar la resolución de nombres, llamado network.dns.disableIPv6. Pues bien, en ese punto, simplemente hay que modificar su valor a true, haciendo doble clic sobre la fila:

Deshabilitando la resolución de nombres para IPv6

A partir de ese momento, y una vez reiniciada la aplicación, ya podremos acceder con Firefox a nuestras aplicaciones en local a toda velocidad.

Solución en Chrome y Firefox

El truco anterior no funcionará con Chrome, donde no he visto cómo desactivar la resolución de nombres en IPv6. Sin embargo, se puede corregir el problema editando editando el archivo hosts, disponible en la carpeta \Windows\System32\drivers\etc, que debe quedar como el siguiente:

Archivo hosts

Es decir, dejamos comentada con la almohadilla (#) la línea que resuelve localhost como “::1” (IPv6) y descomentamos la que lo resuelve como 127.0.0.1 (IPv4). Eso sí, ojo que poder salvar este archivo modificado debéis abrirlo con el bloc de notas o similar como administrador del sistema, en caso contrario no tendréis permisos de escritura. Una vez salvado el archivo, el problema habrá desaparecido.

Además, en este caso, dado que el cambio sobre el archivo hosts afecta a toda la máquina, también Firefox volverá a la normalidad, matando dos pájaros de un tiro, y haciendo innecesaria la utilización del primer método descrito :-)

Fuente:
Publicado en: Variable not found.
lunes, 7 de marzo de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el domingo, 27 de febrero de 2011 hasta el domingo, 06 de marzo de 2011.

Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found
martes, 1 de marzo de 2011
ASP.NET MVCASP.NET MVC utiliza los mismos mecanismos de ASP.NET para la implementación de sitios web localizados, por lo que podemos utilizar los clásicos recursos definidos en la carpeta App_GlobalResources para ir componiendo los interfaces.

De esta forma, los literales de texto de las vistas son sustituidos por expresiones que, ya en tiempo de ejecución, son tomadas del archivo de recursos correspondiente al idioma actual:

image
Sin embargo, recientemente me he encontrado con un escenario en el que, para facilitar el mantenimiento de los contenidos de las vistas, me resultaba mucho más cómodo disponer de versiones distintas de las mismas en sus correspondientes archivos Razor (.cshtml), y seleccionar en tiempo de ejecución cuál de ellas debía ser enviada en función de la cultura del usuario. Eso sí, en caso de no existir una vista específica para la cultura actual, era necesario retornarla en el idioma por defecto.

imageLa idea, como se muestra en la captura de pantalla de la derecha, es modificar ligeramente la convención de nombrado de archivos de vistas del framework para incluir el código del idioma en que está escrito su contenido.

Así, en este caso, asumiremos que las vistas localizadas se llamarán siempre de la forma {vista}_{idioma}. Por ejemplo, la traducción al inglés de la vista “about” estará definida en el archivo “about_en.cshtml” (usando Razor), al francés en “about_fr.cshtml”, y así sucesivamente. Por simplificar, utilizaremos sólo los dos primeros caracteres del idioma, aunque podrían ser referencias culturales completas, como “about_es-es.cshtml”.

Una vez definida la nueva convención, sólo nos falta implementar en el controlador el mecanismo de selección de vistas en función de la cultura actual. En un primer acercamiento, podríamos implementarla directamente sobre las acciones, como en el siguiente ejemplo:
public ActionResult About()
{
    string currentLang = Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName;
    var viewResult = ViewEngines.Engines.FindView
                        (ControllerContext, "About_" + currentLang, null);

    if (viewResult.View == null)
        return View("About_es");
 
    return View("About_" + currentLang);
}
Aunque funcionalmente es correcto, es fácil ver que la introducción de esta lógica contaminaría bastante el código del controlador, además de atentar contra el principio DRY en cuanto tuviéramos varias acciones en las que introducirlo. Obviamente, debemos encontrar otra solución más apropiada y elegante a esta cuestión.

Y como siempre, en ASP.NET MVC existen multitud de fórmulas para resolver problemas de este tipo. En este post vamos a ver dos de ellas: extendiendo el conjunto de ActionResults, y mediante filtros personalizados.

Usando ActionResults

Empezando por el final, el resultado que vamos a lograr es el que podemos ver en el siguiente código de controlador:

public ActionResult About()
{
    return LocalizedView();
}


LocalizedView() no es sino un método rápido para instanciar un LocalizedViewResult, cuya implementación veremos a continuación. La lógica que incluye utilizará los motores de vistas para buscar una vista compuesta por el nombre indicado como parámetro (por defecto el nombre de la acción actual) y la cultura establecida en el hilo de ejecución; de no encontrarse, se mostrará la vista correspondiente a la cultura por defecto.

El código de este ActionResult es el siguiente:

public class LocalizedViewResult : ViewResult
{
    private string _defaultCulture;

    public LocalizedViewResult(string defaultCulture)
    {
        _defaultCulture = defaultCulture;
    }

    public override void ExecuteResult(ControllerContext context)
    {
        string currentCulture = Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName;

        if (string.IsNullOrWhiteSpace(ViewName))   
        {                                          
            ViewName = context.RouteData.GetRequiredString("action");
        }

        var viewResult = ViewEngines.Engines.FindView(context, this.ViewName + "_" + currentCulture, null);

        if (viewResult.View == null)
            ViewName += "_" + _defaultCulture;
        else
            ViewName += "_" + currentCulture;

        base.ExecuteResult(context);
    }
}


Como se puede observar, el método ExecuteResult() obtiene el idioma actual y comprueba si existe una vista que siga la convención de nombrado que hemos definido previamente (vista_idioma.cshtml). Si se encuentra, se anexa al nombre original de la vista el sufijo del idioma; en caso contrario se actúa de la misma forma, pero utilizando el nombre por defecto.

Por último, para hacer más rápido su uso desde las acciones, necesitamos implementar el método LocalizedView() en una clase base de la que deberíamos heredar nuestros controladores:

public class ControladorBase: Controller
{
    public LocalizedViewResult LocalizedView(string viewName = null, object model = null,
                                             string master = null, string defaultLang = "es")
    {
        if (model != null)
        {
            ViewData.Model = model;
        }

        return new LocalizedViewResult(defaultLang)
        {
            ViewName = viewName,
            MasterName = master,
            ViewData = ViewData,
            TempData = TempData,
        };
    }
}


Obviamente, el método LocalizedView() sólo podría ser utilizado desde controladores descendientes de ControladorBase. Si preferís no heredar de un controlador base, siempre podríais crearlo como método extensor de Controller, aunque entonces deberíais invocarlo con el this por delante, y queda algo menos elegante.

Las siguientes acciones muestran posibles usos de esta implementación. Como se puede observar, son bastante explícitas y dejan clara su intencionalidad:

public ActionResult Prueba()
{
    return LocalizedView("About");
}
public ActionResult About()
{
    return LocalizedView();
}


Usando filtros

Los filtros presentan una solución bastante menos intrusiva al problema y, para mi gusto bastante mejor, puesto que no obligaría a modificar la implementación tradicional de las acciones. Para hacernos una idea, lo que pretendemos conseguir es lo siguiente:
[LocalizedView]
public ActionResult About()
{
    return View();
}
El simple hecho de decorar una acción con el atributo LocalizedView provocará que el retorno de la acción sea analizado, y se ejecute la lógica de selección de vistas ya descrita anteriormente. Además, el hecho de ser un filtro hace posible su aplicación a controladores completos, o incluso su aplicación global registrándolo en la inicialización de la aplicación.

El código del filtro personalizado es el siguiente:
public class LocalizedViewAttribute : ActionFilterAttribute
{
    private string _defaultLang;
 
    public LocalizedViewAttribute(string defaultLang = "es")
    {
        _defaultLang = defaultLang;
    }
 
    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
        var viewResult = filterContext.Result as ViewResultBase;
        if (viewResult != null)
        {
            if (string.IsNullOrWhiteSpace(viewResult.ViewName))
            {
                viewResult.ViewName = filterContext.RouteData.GetRequiredString("action");
            }
 
            string currentLang = Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName;
 
            var v = ViewEngines.Engines.FindView(
                filterContext.Controller.ControllerContext,
                viewResult.ViewName + "_" + currentLang, null
            );
 
            if (v.View == null)
                viewResult.ViewName += "_" + _defaultLang;
            else
                viewResult.ViewName += "_" + currentLang;
        }
        base.OnResultExecuting(filterContext);
    }
}
En el código se puede observar que en primer lugar se comprueba que el resultado de la acción sea de tipo ViewResultBase; en caso contrario, es decir, cuando la acción no retorne una vista, simplemente se ejecutará la lógica por defecto.

A continuación, ya asumiendo que la acción retorna una vista, puede observarse la aplicación de la convención de nombrado cuando el nombre de la misma sea nulo, tomándolo de la acción actual. Finalmente, tras comprobar la existencia o no de la vista localizada, se modifica el valor de la propiedad ViewName del resultado, que identifica la vista que finalmente será enviada al cliente.

Desde el punto de vista de la implementación de las acciones queda prácticamente igual de claro que usando la técnica del ActionResult, pero en cambio, ésta requiere menos andamiaje. A continuación, dos posibles ejemplos de uso de este atributo:
[LocalizedView]
public ActionResult About()
{
    return View();
}
 
[LocalizedView("en")]
public ActionResult Prueba()
{
    return View("About");
}

SkydriveY finalmente, por si os interesara ver todo esto en funcionamiento, he dejado un proyecto de demostración en Skydrive (requiere VS2010+MVC 3).



Publicado en: Variable not found.
lunes, 28 de febrero de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el domingo, 20 de febrero de 2011 hasta el domingo, 27 de febrero de 2011.

Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found
lunes, 21 de febrero de 2011
Estos son los enlaces publicados en Variable not found en Facebook y Twitter desde el domingo, 13 de febrero de 2011 hasta el domingo, 20 de febrero de 2011.

Espero que te resulten interesantes. :-)
Y no olvides que puedes seguir esta información en vivo y en directo desde Variable not found en Facebook, o a través de Twitter.

Publicado en: Variable not found