Climens Codelog

Todos los que estamos metidos en la programación en ASP.NET hemos oido hablar a estas alturas del nuevo framework MVC que Microsoft está preparando para el disfrute del personal. Las ventajas de usar un entorno de este tipo frente al clásico ciclo de vida de los WebForms son múltiples, ofreciendo una mejor testabilidad, una correcta separación de las responsabilidades de cada componente y un entorno acorde con el desarrollo actual de aplicaciones web. Ya escribí en su momento sobre la cantidad de cosas que no me gustan de los WebForms.

Pues bien, ya ha salido la primera beta que perfila las funcionalidades de la release final después de haber pasado un proceso de 5 previews que han ido evolucionando el producto en base a las necesidades del equipo de desarrollo pero también de una gran cantidad de desarrolladores que nos hemos embarcado en esta aventura. Aun queda algo de trabajo, pero el framework está mucho más pulido que en las primeras releases y, aunque seguro que algunas cosas se podían haber hecho de otro modo, su publicación final puede revolucionar el panorama del desarrollo en ASP.NET. De hecho esta beta ya no cambia demasiadas cosas respecto a la Preview 5 y el cambio es bastante sencillo.

En Variable Not Found leí por primera vez las novedades que traía, y luego como no, ScottGu y Phil Haack escribieron sus habituales posts describiendo minuciosamente las novedades que nos podemos encontrar más allá del listado que cambios que acompaña la release.

Muchas novedades son sobretodo la mejora de cosas existentes y una mejor integración con Visual Studio pero me ha gustado especialmente la inclusión de JQuery en el proyecto por defecto, siendo el primer producto Microsoft en integrar esta librería tal como se había anunciado. Esta "adopción" permitirá la propagación de esta librería y será de gran ayuda a la hora de desarrollar aplicaciones visualmente más ricas.

Como recomendación, no hay que perder de vista el estupendo proyecto MvcContrib, un proyecto Open Source enfocado a mejorar y añadir funcionalidades al propio framework MVC, como por ejemplo más componentes HTML, ayudas para el testado o integración con varias librerías de IoC. Horas después de sacar la beta, ya han actualizado la librería para funcionar con ella.

Y también no olvidar la librería MVC Futures, que incluye algunas estupendas funcionalidades como ActionLinks genéricos usando expresiones lambda de modo que no se especifica el nombre del controlador y la acción sino directamente el nombre de la clase y del método, impidiendo de ese modo los errores tipográficos que se puedan cometer. ScottGu asegura que estas funcionalidades seguirán siendo actualizadas con los nuevos lanzamientos del MVC Framework y estarán disponibles en la versión 1 cuando llegue el momento, por lo que no hay que temer usarlas.

Y eso es todo. Recomiendo encarecidamente a todo aquel que trabaje desarrollando para ASP.NET que le eche un vistazo al proyecto porque en mi opinión es de lo más interesante que se está desarrollando en el mundo del desarrollo web bajo la plataforma .NET, además de que enfatiza las buenas prácticas y mejora la productividad y la claridad de los desarrollos.

Enlace | ASP.NET MVC

Via | ASP.NET MVC Beta: novedades

El otro día leí un estupendo artículo sobre la difícil mantenibilidad de los WebForms de ASP.NET. Realmente expone las frustraciones a las que nos enfrontamos muchos programadores que trabajamos con esta tecnología de Microsoft, especialmente los que venimos del mundo puramente web y raramente hemos trabajado en VB6 o WinForms.
Entre los motivos que se exponen son los siguientes:

• Algunas cosas sencillas, patrones típicos de HTML/Javascript cuestan mucho o son casi imposibles
• No hay ningún control sobre el HTML generado, dificultando especialmente la conciliación con el diseño original
• Los controles reciben IDs tediosos de manejar desde Javascript, que además cambian si se cambia el control de contenedor
• Los controles a veces no funcionan como deberían y hay que ir investigando porqué se comportan como lo hacen

Yo al final opto muchas veces por usar repeaters, simples y sencillos. Dibujan el HTML tal cual está previsto y así sale todo como está previsto, pero claro, luego vienen los problemas cuando hay que anidar unos dentro de otros: ni se me ocurre abrir el diseñador.

En esta línea, hoy han publicado una continuación hablando del modelo web, lo que conocemos de toda la vida:

• HTTP
• Cookies
• (X)HTML
• CSS
• JavaScript

Una vez entendido es bastante sencillo. Tiene sus inconvenientes pero todo se deriva de la naturaleza del HTTP, donde cada llamada es completamente independiente de la anterior. Eso obligó a crear las cookies y desde el renacimiento del Javascript gracias a la explosión de AJAX conforman un conjunto bastante completo conocido por una infinidad de desarrolladores web alrededor del mundo.

Por lo tanto, para reducir las diferencias entre la programación Windows y la web, los programadores de Microsoft se inventaron:

• Los postbacks
• El ViewState
• El ciclo de vida

Y así nacieron los WebForms. Decidieron reinventar la rueda para captar a los clásicos programadores de VB6 que empezaban en la web cuando apareció el .NET Framework y el Visual Studio .NET por allá por 2003. Pero a los que veníamos de ASP no nos ofrecieron en realidad una continuidad con el medio que conocemos y que por más que pase el tiempo no acabamos de comprender el nuevo modelo pensando que "antes era más sencillo". No es lo que yo llamo progreso.

Un ejemplo reciente: me preguntaron porque si movían opciones de un ListBox a otro por Javascript y luego hacían un Request para recoger el valor de la lista en la acción, devolvía null. Pues simplemente porque ese tipo de controles meten su valor en el ViewState para "completar" la información que HTML por sí mismo no da. Así que la solución es copiar el valor en un campo oculto y luego recogerlo, teniendo que hacer manualmente lo que ASP.NET hace automáticamente solamente porque usando los eventos de .NET, cada movimiento entre listas obliga a recargar la página (no con AJAX, pero el problema es parecido). Y con razón me dicen que antes era más sencillo. No les puedo decir que no.

Así que tengo esperanza en los frameworks MVC. He probado MonoRail y los resultados han sido muy positivos: todo bien separado, diseño tal cual había sido concebido por los creativos, testeo de cada una de las partes, etc. Ahora va haciendo camino ASP.NET MVC (y en Codeplex con código fuente y ejemplos), que no es ni mejor ni peor pero probablemente sea más fácil convencer a las altas esferas si lleva el ADN de Microsoft y no el de Open Source (es lo que tiene el vendor lock-in). En cualquier caso, sea con uno o con otro, creo que es el camino a seguir para librarse definitivamente de los WebForms y volver a jugar en terreno conocido.

Via | Working with the web model [lostechies.com]

Hacía tiempo que tenía pendiente en mi trabajo probar el Selenium, pero era una de esas cosas que uno lo mira un día, no le acaba de ver el punto y lo deja para más adelante. Y no es que no sea útil, realmente es completo, funciona en varias plataformas, tanto de navegadores como de sistemas operativos. Tiene un IDE sencillo que genera scripts e incluso es ámpliamente usado en Ruby on Rails, el framework de moda. Pero aun así, no me acabó de entrar por el ojo.

Una de las pegas que siempre le encontré fue que la integración en los proyectos web de .NET y en tests de NUnit no era lo más cómodo ni simple. Barreras, en definitiva. Pero he descubierto que no era el único que tenía esta impresión: he visto una comparativa de WatiN, Watir y Selenium (siempre hay alguien que te facilita el trabajo). Leyéndolo he decidido probar WatiN.

Y la verdad que la experiencia ha sido muy positiva. Los tests son sencillos de escribir, funcionan como es de esperar y con un lenguaje sencillo y claro. He probado primero algo parecido al ejemplo que hay en su página de inicio y por desgracia no ha funcionado a la primera. Pero estaba claro que algo estaba haciendo mal porque todo se colgaba a la hora de cerrar el Internet Explorer... Después de darle un par de vueltas he desactivado todos los plugins y voilà: funcionaba perfectamente. Al final era el Flashget que interactuaba de forma un tanto extraña.

Después me he puesto a jugar validando alerts de javascript y se ha complicado un poquillo, pero recurriendo a las listas de correo, alguien había preguntado ya mis dudas, como siempre. Al final el uso del DialogHandler ha quedado algo tal que así:

 
        [Test]
        public void BasicTest()
        {
            using(IE ie = new IE("http://intranet/formulario.aspx"))
            {
                AlertDialogHandler alertHandler = new AlertDialogHandler();
                ie.DialogWatcher.Add(alertHandler);
 
                ie.Button(Find.ByName("Continuar")).ClickNoWait();
 
                alertHandler.WaitUntilExists(5);
                alertHandler.OKButton.Click();
            }
        }
 

Realmente es duro y laborioso escribir este tipo de tests, pero como puede que mi futuro pase por diseñar un nuevo producto más o menos complejo durante unos cuantos meses, el testado de la interfaz de usuario será importante para validar que todo funciona como es debido.

• Link: WatiN, Watir and Selenium reviewed