Una de las mejoras sencillas y poco llamativas en primera instancia que ha incluido el Service Pack 1 de .NET 3.5 y Visual Studio 2008 es la consolidación de Scripts. Sin embargo es algo interesante que conviene conocer.

Se trata básicamente de evitar que el navegador tenga que descargar multitud de pequeños archivos de Script desde el servidor, sustituyéndolos de manera automática por una sola descarga combonada, que es más eficiente y rápida como demostraré enseguida.

Es la típica característica que va a pasar inadvertida para la mayoría de los programadores Web pero que es interesante, y por eso me ha apetecido contarla en detalle aquí. Para ello he desarrollado un ejemplo muy simple pero que da una idea de la utilidad de esta característica. En el siguiente vídeo muestro cómo funciona la consolidación de Scripts mediante las nuevas etiquetas CompositeScript. También muestro un control desconocido pero interesante y pensado para ayudarnos a trabajar con esta característica: el control ScriptReferenceProfiler.

Si no ves bien el vídeo pulsa aquí

Este vídeo es como los muchos que puedes encontrar, junto con la teoría correspondiente, en cualquiera de nuestros cursos online de campusMVP sobre tecnología Microsoft, sólo que en los cursos los vídeos son de mejor calidad porque no nos limitan los tamaños de SoapBox, YouTube y similares :-)

¡Espero que os interese!

Hay veces que necesitaremos usar programáticamente un ScriptManager dentro de una página, por ejemplo para añadir dinámicamente referencias a Scripts o a servicios Web o WCF. Para ello deberemos automatizar el control ScriptManager que toda página AJAX debe tener, pero ¿qué pasa si no existe ese control?

Para asegurarnos de que el control está añadido a la página y que podemos utilizarlo podemos emplear el método estático GetCurrent de la clase ScriptManager para verificar su existencia, así:

public static bool IsScriptManagerPresent(Page p)
{
   ScriptManager Smgr = ScriptManager.GetCurrent(p);
   return (Smgr != null);
}

Con esta sencilla función podremos averiguar si hay un Scriptmanager presente o no.

Es interesante notar que este método funciona y devuelve el valor correcto incluso cuando el ScriptManager no está presente en la página actual sino en la página plantilla (Master Page) que la contiene. No obstante es importante darse cuenta de que en ese caso devovlerá true incluso si la Master Page tiene un ScriptManager aunque no tengamos un ScriptManagerProxy (SMP) en la nuestra, por lo que si obtuviésemos una referencia al ScriptManager estaríamos trabajando directamente con el de la MP aún sin un SMP.

En mi anterior post comentaba los peligros de usar alegremente los controles UpdatePanel de AJAX y mostraba con la excelente herramienta Fiddler cómo eran las peticiones que se enviaban y recibían.

Alguien me ha preguntado cómo hago para poder utilizar Fiddler con el servidor Web de desarrollo que viene con Visual Studio (conocido comunmente como Cassini), ya que por mucho que actives Fiddler por defecto no captura las peticiones hechas a dicho servidor.

El servidor de desarrollo sólo admite peticiones locales y accedemos a ése a través de una URL del tipo:

http://locahost:3572/miapp

Eligiendo un puerto aleatorio de cada vez.

Cuando lanzas Fiddler éste se coloca como proxy de Internet Explorer interceptando todas las llamadas que hace éste a las páginas Web. Lo que ocurre es que IE cuando detecta que una llamada se va a hacer en local (contra localhost vamos) automáticamente hace caso omiso de los posibles proxy que hubiera y lanza la petición directamente, de ahí que Fiddler no funcione.

Podemos solucionar este problema de una manera sencilla usando el siguiente truco.

Modificación al vuelo de la URL en Fiddler

La herramienta Fiddler nos permite responder a diferentes eventos mientras realiza una petición, los cuales podemos interceptar con código de Script. Se puede ver el ´codigo por defecto de estos eventos usando el menú "Rules" de fiddler, así:

Uno de estos eventos se produce justo antes de lanzar la petición desde el proxy y se llama "OnBeforeRequest". Por lo tanto podemos modificar la URL local para que IE piense que es externa, y volver a modificarla en el evento mencionado antes de que el proxy lance la petición. La manera más fácil es añadir a la palabra 'localhost' un punto justo al final. Así IE no la reconocerá como la URL local y la petición pasará a través de Fiddler. En el evento OnBeforeRequest sólo tenemos que añadir los siguiente al principio:

        if (oSession.host.substr(0, 10)=="localhost.")
        {
                 oSession.host=oSession.host.replace("localhost.", "127.0.0.1");
        } 

Esto hace que cuando Fiddler detecta una petición a cualquier url que empiece por "localhost." la transforma en una llamada a la misma URL dentro de "127.0.0.1", que es equivalente.

Obviamente podríamos usar cualquier otro añadido a la URL local para cambiar la petición. Incluso en lugar de un simple punto añadir un subdominio especial del estilo ".local", para que fueran URLs del estilo "localhost.local" o algo así, cambiando por tanto el pequeño código de intercepción en el evento, pero el punto es el camino más rápido y va de maravilla.

Así que ya sabes, haz ese retoque en el evento, y a partir de entonces lanza tu aplicación y justo tras haber lanzado Fiddler añádele un punto a localhost al final para que Fiddler entre en acción y puedas analizar con detalle todo el trasiego de información entre cliente y servidor que produce tu aplicación, incluyendo peticiones AJAX encualquier puerto :-)

Las tecnologías de Microsoft han adolecido tradicionalmente de un problema que es a la vez, paradójicamente, su mayor ventaja: la sencillez aparente de uso. Pienso que  la clave del éxito de Windows, Office y otros muchos productos de la casa de Redmond ha sido y es su sencillez de uso. Pero esta misma sencillez de uso se convierte también un arma de doble filo: hace que la gente se quede en la superficie de las cosas, sin comprender bien las consecuencias de lo que hacen. Ha pasado toda la vida con las versiones de servidor de Windows, y ha pasado y pasa con las herramientas de desarrollo. Al ser fáciles de configurar y utilizar la gente enseguida "controla" la tecnología correspondiente, lo cual es un error grave.

En este caso me estoy refiriendo en concreto a la tecnología ASP.NET AJAX que tanto facilita el desarrollo de aplicaciones de interfaz avanzada para la Web. Desde mi punto de vista el Update Panel es una obra de arte que debería llevar un premio al diseño de componentes y arquitecturas. Antes de su existencia la creación de aplicaciones AJAX era compleja, a pesar de los diversos frameworks para ello que existían. El uso de los Update Panel convierte en algo realmente sencillo el crear aplicaciones Web con capacidad de respuesta rápida y sin refresco de página. Una maravilla vamos.

Lo cierto es que su sencillez ha hecho que la gran mayoría de los que los utilizan lo hagan sin un buen criterio. Todo el mundo "sabe" hacer aplicaciones AJAX hoy en día. Los lamentos vienen después cuando las aplicaciones deben escalar y ser eficientes, como en casi todos los casos en los que se ve a diferencia entre un buen y un mal programador.

Veamos qué pasa cuando colocas un Update Panel en una página ASPX para hacer algo tan tonto como actualizar la hora actual en una etiqueta. En una página vacía colocas un ScriptManager, un Update Panel y dentro de éste una etiqueta y un botón. al pulsar el botón asignas en un evento de servidor la hora actual a la etiqueta, así:

    protected void Button1_Click(object sender, EventArgs e)
    {
        Label1.Text = DateTime.Now.ToShortTimeString();
    }

Una chorrada total. Vale ahora ejecutas y voilá!, mágicamente el Update Panel hace su trabajo y ves aparecer la hora en la eiqueta sin hacer un postback tradicional al servidor ysin que la página ni siquiere parpadee.

Estupendo. Pero vamos a analizar qué pasa entre bambalinas y más en concreto qué información se envía y se recibe a y desde el servidor. Para ello he utilizado a mi fiel amigo Fiddler, el analizador de tráfico que más me gusta. El resultado de la petición de ida y vuelta del Update Panel es el que se puede ver en esta figura:

En la parte de arriba podemos ver la petición que se envía y en la de abajo la respuesta recibida. ¡En total 889 caracteres (casi 1 KB) para realmente obtener una información (la hora) que ocupa solamente 8 caracteres!

Impresionante. Ahora imagínate esta situación en una página compleja en la que el avezado programador se ha dedicado a dejar caer UpdatePanels por doquier (cosa muy común y una mala práctica). Ahí es nada.

Existen formas mucho más eficientes de conseguir lo mismo eficientemente usando el mucho más amplio framework de ASP.NET AJAX, tal y como se explica en nuestro curso de ASP.NET AJAX.

La conclusión es que hay que utilizar las tecnologías con cabeza y comprendiendo lo que se hace. Lo fácil de usar es un arma de doble filo.

Como seguramente sabrás si eres asiduo lector o lectora de este blog, hace un par de semanas participé como ponente en el lanzamiento de Visual Studio 2008, durante los TechDays, The Evolution Show, en Madrid.

Como parte de ese evento, aparte de la consabida ponencia, participé en una sesión de Ask The Experts (ATE) el segundo día por la tarde, enla que tuve oportunidad de conversar con mucha gente (antes,durante y después) sobre todo tipo de cuestiones técnicas relacionadas con el desarrollo Web. El ATE es, básicamente, una lotería. LLegas, y la gente que está allí te empieza a preguntar lo que se le ocurra, así que nunca sabes por dónde te van a salir. En esta ocasión la cosa fue estupenda, y los asistentes hicieron muchas preguntas interesantes. ¡Gracias a todos los que asistísteis! :-)

Los buenos chicos de Microsoft grabaron todo el ATE para compartirlo en su página Comando Tomate, la última ida de olla de esos cracks que trabajan en DPE de Microsoft Ibérica.

Creo que a muchos de los que visitáis asiduamente este blog os pueden interesar algunas de las preguntas que contesté allí, así que os dejo los correspondientes vídeos (necesitarás Silverlight 1.0 para poder verlos).

· En el primero de ellos hablo sobre cómo construir aplicaciones Web en varias capas usando controles ObjectDataSource. También sobre qué es Expression Web y cómo encaja dentro de Visual Studio 2005/2008. Finalmente también contesto a la preocupación de uno de los asistentes sobre cómo proteger el código de nuestros desarrollos con ofuscadores:

· En el segundo vídeo me meto en harina con un tema peliagudo que me lanza un asistente algo despistado. Me pregunta sobre cómo manejar consultas con miles de registros en la interfaz de usuario, algo que considero muy interesante. El problema es que el buen hombre estaba todo el rato pensando en aplicaciones de escritorio (Windows Forms) y mi charla era de desarrollo Web, por lo que todo lo que le comentaba no le convencía y negaba con la cabeza continuamente, lo que me estaba poniendo un poco frenético, la verdad. Al final se dió cuenta de que estábamos hablando de cosas diferentes. No obstante el tema era de mucho interés y creo que lo que cuento puede interesar a muchos (siempre pensando en desarrollo web, claro). También hablo de cómo encapsular capacidades AJAX en controles de usuario para reutilizar en las páginas:

· Por fin, en el último vídeo del ATE hablo sobre el trabajo en equipo con Expression Web y Visual Studio, y sobre cómo es la mejor forma de utilizar DataSets tipados y LINQ To SQL en aplicaciones con requisitos cambiantes:

¡Espero que os guste! :-)