[CodeSnippet] Mostrar un Label en ASP.NET por 3 segundos

Requerimiento: Después de procesar una operación contra la base de datos, se desea mostrar un mensaje de confirmación en un Label, pero que el mismo desaparezca en unos tres segundos, ver pregunta.

Solución: Conociendo el funcionamiento de la infraestructura web, el browser es quien automáticamente pasado los 3 segundos debe ocultar el mensaje mostrado. Dado que la funcionalidad que necesitamos es del lado del cliente, la opción es usar JavaScript. Dentro de los eventos Timing de JavaScript, existe el método setTimeout() que pertenece al DOM Window, este método permite ejecutar una sentencia o función JavaScript, después de un determinado tiempo. Y la propuesta será tener dos funciones, una que muestre el “Label” y que a la vez llame dentro de 3 segundos a otra función que oculta el Label. Y finalmente para integrarlo con nuestro botón de ASP.NET, al finalizar la ejecución del mismo podemos registrar el script del lado cliente, usando el método RegisterStartupScript de la propiedad Page.ClientScript. Nota: no es necesario usar un Label, podemos usar el elemento HTML Div para mostrar el mensaje.

Código ASPX:

   1: <head runat="server">
   2:     <title></title>
   3:     <script type="text/javascript" language="javascript">
   1:  
   2:         function MostrarLabel() {
   3:             setTimeout("OcultarLabel()", 3000);
   4:             var msj = document.getElementById("lblMensaje");
   5:             msj.style.visibility = "visible";
   6:         }
   7:         function OcultarLabel() {
   8:             var msj = document.getElementById("lblMensaje");
   9:             msj.style.visibility = "hidden";
  10:         }

</script>

   4: </head>
   5: <body >
   6:     <form id="form1" runat="server" >
   7:     <div>
   8:         <div id="lblMensaje" style="visibility:hidden;">
   9:           <h3>Mensaje mostrado por tres segundos...</h3> 
  10:           <br />
  11:         </div>                
  12:         <input type="button" value="click aqui" onclick="MostrarLabel()" />
  13:         <asp:Button ID="btnMostrarMensaje" runat="server" Text="Mostrar" 
  14:             onclick="btnMostrarMensaje_Click" />
  15:          <asp:Button ID="btnNada" runat="server" Text="No Muestra nada"  />        
  16:     </div>
  17:     </form>
  18: </body>

Código Evento:

   1: protected void btnMostrarMensaje_Click(object sender, EventArgs e)
   2:   {  
   3:     //codigo de operaciones contra la base de datos
   4:     Page.ClientScript.RegisterStartupScript(
   5:        Page.ClientScript.GetType(), "onLoad", "MostrarLabel();", true);
   6:   }

Navegadores Probados: Todos sobre Windows Vista SP1.

  • Firefox 3.0.6
  • Internet Explorer 7.0.6001
  • Opera 9.52
  • Google Chrome 1.0.154.48
  • Safari 3.1.2

Notas:

Recursos:

P.D.: Cuando tenga este tipo de requerimientos, no inventen marcianadas para hacerlo con ASP.NET 3.5++, puede ser tan simple de hacerlo con JavaScript. Ojo, tampoco se quiere concluir que todo lo vamos hacer con JavaScript, debemos buscar el equilibrio, sin afectar la seguridad y el rendimiento.

Saludos,

Recomendaciones para la Adopcion de AJAX usando ASP.NET AJAX

Simple: “No usarlo”… (no tomarlo literalmente)

http://sergiot2.com/blogimages/2009/02Feb/18_aspnet_ajax_logo.png

Repasando: Como ya hemos comentado, la infraestructura que da soporte a las aplicaciones Web es diferente a una aplicación de escritorio. Si bien esta infraestructura es rica en acceso (acceder desde cualquier parte del mundo con una conexión a Internet), también tiene desventajas y una de ellas son los “viajes” que tienen que hacer al servidor Web. Si bien en el navegador estamos viendo una réplica de la información (en formato html), si queremos refrescar la información o hacer alguna operación, nuestro pedido (request) viaja desde nuestra PC hasta el servidor Web, que puede estar al otro lado del mundo, pero gracias al protocolo HTTP se pueden comunicar. Y cada vez que hacemos un request al servidor, tenemos que esperar que se refresque nuevamente toda la página (algunos navegadores usan Cache para los estilos y diseño) lo que da una apariencia de cargar más rápido. De ahí la siguiente necesidad de las aplicaciones Web, después de quedar la satisfecha la necesidad de que sean dinámicas (tecnologías de servidor, asp, php, jsp, etc), es la necesidad de mejorar la experiencia de usuario de las aplicaciones Web, y que puedan ser semejantes al estilo de una aplicación de escritorio, han habido muchos intentos por establecer la tecnología que permitiría mejorar la experiencia de usuario de una Aplicación Web, todos tenían que ver con el complemento del lado del cliente para lograr esto. Pero en los últimos años, los esfuerzos han estado centrados en AJAX, y en las aplicaciones RIA, considerando a estas últimas como producto: Silverlight y Flash, por que las aplicaciones AJAX también hacen una aplicación RIA.

Frameworks AJAX: Implementar AJAX usando directamente el objeto XMLHttpRequest, puede llevarnos a escribir código más limpio y más óptimo, pero el esfuerzo y tiempo invertido para lograr grandes cosas, puede ser muy alto (dependiendo del escenario). Y es por eso que existen los frameworks AJAX, para todos los gustos, sabores, y colores. Aquí hay una lista de un montón de Frameworks Ajax, también pueden verlos agrupados por lenguaje. Microsoft, también liberó para los desarrolladores .NET (y no .Net) un Framework AJAX llamado ASP.NET AJAX.

ASP.NET AJAX, tiene dos componentes: Microsoft Ajax Library (que podría ser usado con PHP, ver WebCast), y otro componente del lado del servidor llamado ASP.NET AJAX Extensions, y que es netamente para integrarse con el Page Framework de ASP.NET 2.0+ (VS2005/VS2008), pueden ver más detalles de la arquitectura de ASP.NET AJAX en el siguiente artículo. ASP.NET AJAX, puede ser una solución mágica, por que rápidamente podemos tener nuestras aplicaciones Web, usando AJAX con sólo arrastrar el control UpdatePanel, podemos tener implementando AJAX en aplicaciones existentes, ver WebCast. Si tienen un mantenedor con una barra de botones, un GridView para mostrar la lista, y un FormView para las demás operaciones, bastaría colocar los 3 controles dentro de un UpdatePanel cada uno, y mágicamente ya tenemos implementado AJAX dentro de nuestra aplicación.

Problema de la Magia, como todo producto mágico, tiene sus costos por detrás. Aunque ASP.NET AJAX maneja postbacks asíncronos con el servidor Web, la información que viaja entre cliente y servidor no es la más óptima, hombre que la magia tiene su coste. Y esto debido a que si no hacemos una buena administración del ViewState, este estará viajando entre los postbacks asíncronos, revisar este artículo para ver un ejemplo. Además de que ASP.NET AJAX es un framework centrado en el Servidor viaja información+diseño entre postbacks asíncronos, a diferencia de un framework centrado en el cliente, que sólo viaja datos entre cliente y servidor, pero hay que “actualizar el diseño” manualmente usando JavaScript y DOM. Este artículo tiene resultados muy interesantes en cuanto a comparación de frameworks de AJAX para ASP.NET.

Alternativa, Una alternativa dentro de ASP.NET AJAX es usar los PageMethods, para que desde JavaScript podamos llamar a los mismos, o también llamar desde JavaScript a Web Services. Con esto garantizamos la transferencia sólo de información, y el diseño hay que modificarlo con JavaScript. Revisar este ejemplo de JavaScript y PageMethods, y JQuery y PageMethods.

Recomendaciones, se que fue mucho floro para llegar a las recomendaciones, pero fue necesario. Si cociendo la “magia” que hay detrás de ASP.NET AJAX, hemos decidido usarlo, por que la aplicación no requiere un alto rendimiento, sólo estará disponible dentro de nuestra empresa (y no a toda la internet, ósea cantidad de usuarios limitada), o hemos visto que en el prototipo, los resultados son aceptables. Hay algunas recomendaciones básicas para usar ASP.NET AJAX:

  1. No usarlo. No usarlo hasta que la página web este funcionando al 100%. La magia de ASP.NET AJAX, a través del UpdatePanel, permite que luego de que la página este funcionando, arrastramos al control UpdatePanel, colocamos nuestros controles de ASP.NET dentro del UpdatePanel, y nuestra página aspx ya tiene AJAX, con sólo arrastrar un control, en este WebCast, se muestra como a una aplicación Web existente (de otro autor), la implementación de ASP.NET AJAX usando el UpdtePanel fue sencilla y no requirió cambiar el modelo de programación. La recomendación, que motiva a no usar ASP.NET AJAX hasta que la página este funcionando, es debido a que muchas veces suele confundirse los errores, y no se sabe si la página no funciona por que el UpdatePanel tiene un bug, o los otros controles que estamos usando tiene bug, y raras veces se piensa que el código que hemos hecho es el que tiene el bug. Por eso, si nos centramos principalmente en hacer funcionar la página al inicio, el rango de causas de errores disminuirá por que no incluye los que pueda producir el uso de ASP.NET AJAX, lo que hará más fácil identificarlos, y solucionarlos, y esto sobretodo para procesos complejos, que tienen que implementarse. En los proyectos participado o en las consultorías y mentoring que hemos impartido con 3Dev, este era un problema frecuente, se tiende a responsabilizar al UpdatePanel de cualquier error que suceda en la página, y siempre hay que hacerse esta pregunta: –la página funciona correctamente sin el UpdatePanel?, y después de remover el UpdatePanel queda claro cual es el origen del error. Un amigo (Luis B.), en tono jocoso, quería demandar a Bill Gates por que ASP.NET Ajax no funcionaba, después de remover el UpdatePanel ya no dijo nada :D.
  2. El UpdatePanel no es barita mágica. Si bien es tan sencillo agregar AJAX a nuestras aplicaciones Web usando el control UpdatePanel, tampoco se debe hacer un uso indiscriminado del mismo. Por ejemplo, dentro de un formulario Web, sólo agregar a los controles que se van actualizar dentro de un UpdatePanel, en una página de mantenimiento sólo a los controles principales como un control GridView, formView, y al menú, pero no a toda la página, la idea de AJAX es actualizar la página asíncronamente para tener una mejor experiencia del usuario, pero si vamos a actualizar toda la página no tiene sentido. Una forma de evitar tener que usar un control UpdatePanel en todo, es usar AsyncPosBackTrigger en un UpdatePanel, un ejemplo, con esto evitamos colocar todos los controles en UpdatePanels. Recuerden que un UpdatePanel se actualiza, cuando un control dentro del mismo produce un PostBack, entonces se actualiza el UpdatePanel y se produce un PostBack asíncrono, o también se actualiza cuando otro UpdatePanel se actualiza, es decir, que si una página tenemos tres UpdatePanels que no están relacionados, si actualizo uno de ellos automáticamente se actualizan los otros dos. Para solucionar este último problema, se puede actualizar el UpdatePanel manual, es decir programáticamente, un ejemplo, aunque esta un poco simple el último ejemplo un posible escenario es si es que dentro de una página aspx, tengo 3 UpdatePanels, y sólo voy actualizar dos, la forma correcta es asignar a la propiedad UpdateMode el valor de Conditional, así solo se actualizarán cuando se produzca un evento dentro de ellos, o cuando se llame explícitamente al método Update del control UpdatePanel.
  3. Cuidado con el dedo compulsivo. Uno de los detalles de usar AJAX, son que cuando se produce un postback asíncrono el usuario (ni el mismo desarrollador) sabe si se ejecuto o no el evento, y entonces vuelven hacer varios clic en el botón para asegurarse que hicieron clic. Es por eso que es necesario usar indicadores para indicarle al usuario, que su pedido se esta procesando, con ASP.NET AJAX pueden usar el control UpdateProgress, pero mucho mejor si lo hacen centrado y bloquean la pantalla.

AjaxControlToolkit (ACT), un juego de controles (ajaxcontroltoolkit.dll) liberados junto con ASP.NET AJAX, hay algunos controles útiles como el control AutoComplete, y bueno otros que se podrían mejorar. Y al igual que ASP.NET AJAX, hay que tener cuidado con el uso del ACT, evaluarlo en nuestros escenarios. Aquí pueden ver los ejemplos de los controles Online, y en algunos controles se aplican la misma regla que el UpdatePanel, primero verifiquen el funcionamiento básico de su página, antes de usar algunos controles del ACT. Ejemplos del ACT, los pueden descargar de la página del mismo en CodePlex, además de los ejemplos se encuentra el código fuente del ACT. Nota: los ejemplos son los mismo que están online, y todos los controles tienen un ejemplo, lo pendiente es revisar que CSS usa el control que vamos a probar, y eso copiarlo a nuestro sitio Web.

Destacado:

Artículos, Videos, Ejemplos:

Saludos,

Buenas practicas de programacion y tecnicas para liberar recursos, para tener una aplicacion mas rapida ¿?

http://sergiot2.com/blogimages/2009/02Feb/06-Tortuga-Lenta-o-Liebre-Rapida.jpg

¿La aplicación web de Geeks.ms es rápida?

¿Rápida, para quién?. Para el programador?, para el usuario?, o para el jefe de proyectos?. ¿Cuántos segundos debe tomar cargar una aplicación para que sea rápida? –4 segundos, 8 segundos, 15 segundos?

Y las mismas preguntas podemos hacernos, para considerar una aplicación lenta.

Antes de jugar al teléfono malogrado, se debería tener un límite para considerar a una aplicación “lenta”. Si dentro de los requerimientos no funcionales, se dice que ningún formulario debe tomar más de 15 segundos para completar una operación, ya se sabe que si página o formulario toma 20 segundos, se podría decir que es lenta. Entonces, para poder definir si una aplicación es lenta o es rápida, el límite debería estar definido en los requerimientos no funcionales, y si no lo esta (en muchos casos), antes de optimizar se debería especificar cual será el tiempo de referencia a tomar, para considerar a una aplicación rápida o lenta. Así cuando llegue alguna queja del usuario por que quiere una aplicación sea más rápida, se revisa si el formulario esta dentro de los límites, y si aún así el usuario quiere más rápida (nuevos límites) ese es otro precio.

¿Todas los formularios requieren optimización?

Normalmente los procesos de mantenimiento, debería ser los más rápidos (usamos el término rápido como comparación no como medida) a comparación de los procesos de búsquedas, cargas masivas, o exportar información o procesos de fin de mes.

Veamos, si una página de mantenimiento sólo requiere hacer operaciones de consulta (muchos registros), inserción (un registro), actualización (un registro), y eliminación (un registro), no debería tomar más tiempo que otras páginas de procesos más complejos. Y para lograr esto debemos tener algunos detalles en cuenta, que son básicos:

  • Administrar correctamente las conexiones a la base de datos, liberar los recursos después de usarlos. Desde .Net, podemos usar la clausula using, para asegurarnos de liberar los recursos. Revisar esta entrada: Ado.Net y Using.
  • Paginar los resultados desde la base de datos, y no desde el cliente. Hay algunos controles mágicos que ofrecen, paginación, pero a qué costo?. Por ejemplo para paginar en Oracle podemos usar ROWNUM, y en SQL Server podemos usar ROW_NUMBER, obviamente que para lograr una paginación del lado de cliente, involucra que tengamos que pasarle dos parámetros más como el registro inicial (startRowIndex) y la cantidad de resultados (maximumRows), además de que tengamos que hacer otro método y procedure, para “contar”, ya que necesitamos saber cuantas páginas tiene el resultado.

Si seguimos estas dos reglas básicas, los formularios de mantenimiento deben ser los más rápidas de toda nuestra aplicación. Y entonces, páginas o formularios a optimizar son los procesos de búsquedas, operaciones masivas, generación de reportes, entre otros procesos complejos (1).

¿Pero qué pasa, si toda la aplicación esta lenta? Sean de mantenimientos simples o complejos, o procesos, todas demoran mucho a comparación de otra aplicación (una aplicación Web frente a una Windows). Sobre todo en esas migraciones por tendencia o moda de una aplicación Windows a Web, sobretodo si no se tiene muy claro la infraestructura de una aplicación web, el usuario dirá: pero en la aplicación Windows era más rápido, como le explicas que el navegador tiene que hacer un viaje al servidor, o lo que se conoce como postback en asp.net,  para poder ver los resultados. Y la migración de una aplicación se puede vender por dos cosas: por mejoras de procesos, o por que va ser más rápido, entonces nuevamente por que la web mas lenta, se preguntará el usuario. Entonces, si la mayoría de formularios están lentos a comparación de su previa versión, habrá que revisar el código base o código común (2).

¿Juego de Herramientas o técnicas del buen optimizador?

  1. Profiler del motor de base de datos. En el escenario 1, y el escenario 2, es bueno identificar cuales son las operaciones que se están haciendo contra una base de datos, y el tiempo que están tomando estas operaciones, la cantidad de operaciones que se esta haciendo, quizás es redundante el número de operaciones. Imaginen, que están haciendo un búsqueda sobre un catálogo de libros, tenemos varios millones de libros en nuestro catalogo, y tenemos que buscar por título, descripción, contenidos. Para SQL Server nosotros tenemos SQL Profiler. Después de analizar podemos llegar a dos conclusiones, una determina consulta esta tomando un tiempo mayor al esperado, hay que determinar si podemos hacer alguna mejora para incrementar la performance del servidor de datos, también revisar esta presentación: buenas prácticas para mejorar el rendimiento en un servidor SQL Server. Y si el problema, no esta en la consulta, si no en la recurrencia a la información?, en este escenario donde la información mostrada cambia pocas veces (una noticia de un diario, las entradas de un blog) se puede hacer el uso de técnicas de Cache, atención si la aplicación tiene alta transaccionalidad es decir se necesita hacer operaciones con la información más reciente, imaginad hacer ventas de productos que tienen stock 4 (por que así se guardo en la cache) cuando un producto ya no tiene ese stock 4, en este último escenario no es aplicable el uso de Cache.
  2. Profiler de nuestro código. Es una manera de identificar cuales son los cuellos de botella dentro de nuestro código, o para optimizar hasta la última línea de código. [.Net] Carlos Walzer, por ejemplo nos muestra el uso de la herramienta dotTrace 3.0, para analizar el tiempo y la cantidad de cada una de las llamadas dentro de .Net, con la cual podemos llegar a la mejor forma de hacer las cosas, revisar la serie: Cazando mitos en ADO.NET.
  3. Profiler del render del Html (Web). En una aplicación Web, hay otro detalle a tener en cuenta y es el tamaño del html enviado al navegador. Una excelente herramienta para detectar motivas de lentitud en la carga de una aplicación web es usar YSlow, y si están usando asp.net también puede usar la característica Tracing, con la cual podemos identificar los métodos dentro del ciclo de vida de ejecución de una página ASP.NET, además del tiempo de ejecución de los mismos, para saber cual demora más; lo otro que podemos identificar el tamaño de bytes que ocupa el render de todos los controles de la página, así como el ViewState ese monstruito que es bueno pero a la vez es malo que están ocupando. El ViewState sólo debería ser usado cuando es verdaderamente útil, todos los controles por defecto tienen habilitado el ViewState. Por ejemplo si ustedes hacen ver código fuente html de esta página, encontrarán un elemento llamado: __VIEWSTATE, y en este caso de Geeks.ms, y si vamos a un decoder online, veremos que sólo tiene un valor, que es el código de la página, si están desarrollando con ASP.NET, hagan “View in Browser” y vean el tamaño del ViewState, y vean con el decoder que se esta guardando.

Otro detalle a tener es al no liberarse correctamente los recursos y ocupar memoria, “fuga de memoria”. Dentro de Windows existe una herramienta llamada WinDBG, que puede ser usado para identificar fugas de memoria dentro de .Net por ejemplo. Y específicamente para .Net podemos usar el CLR Profiler, como en este escenario: Cómo cazar una fuga de memoria en .Net, también podemos usar .NET Memory Profiler.

Resumiendo

  1. Se debe especificar, el rango para que una aplicación sea considera rápida o lenta.
  2. Los formularios de mantenimiento deberían ser los más rápidos dentro de nuestra aplicación, por que las operaciones son simples, y debemos seguir las reglas básicas, de paginación del lado del servidor de datos y liberación de recursos (conexiones).
  3. Los formularios especiales, necesitan de herramientas especializadas para identificar donde se encuentra el cuello de botella, o los lugares posibles de optimización. Para ello disponemos de Profilers, a nivel del servidor de datos, como también a nivel del código de nuestra aplicación.
  4. Para aplicaciones Web, asegurarse que el render del html sea el adecuado.
  5. Tener cuidado con las fugas de memoria.

P.D.: Espero que esta lista de herramientas, ayuden a mejorar el rendimiento de sus aplicaciones, en algún momento mostrare algunas de ellas en determinados escenarios para ver su utilidad más claramente, quedan en los drafts como constancia.

Oros artículos de interés:

Saludos,