está claro que en este ejemplo, a pesar de lo espectaculares que son los números relativos, el impacto es mínimo. Y en muchos otros casos puede que también sea así, y el uso de un UpdatePanel está más que justificado gracias a la productividad que obtenemos.
No obstante vamos a ver cómo podemos crear una versión de esta misma página que esté optimizada y nos genere el mínimo tráfico posible. así aprenderemos a solventar casos más graves en los que esta sobrecarga adicional no esté justificada o nos produzca problemas graves de rendimiento.
Para ello vamos a explicar lo que se conoce como Retrollamadas de Red a Métodos Estáticos, o de manera más común, Métodos de Página.
esta técnica, como su propio nombre indica, nos permite definir dentro de la página uno o más métodos que serán accesibles directamente a través de Internet desde el navegador, siendo sólo necesario el uso de código Javascript. De este modo en lugar de llamar a la página completa, que es lo que hacíamos antes, ahora llama- remos exclusivamente al método en cuestión, obteniendo una respuesta optimizada como enseguida veremos con el ejemplo.
añade otra página al proyecto con el nombre “MetodosDePagina.aspx”. arrastra a su superficie de diseño un control ScriptManager. vete a la vista de código fuente de la página e introduce una etiqueta <div> para definir una capa hTML. otórgale el nombre “divhora” y en su estilo asígnale un color rojo y un tamaño de texto grande. Nos servirá para mostrar la hora y hará las veces de la etiqueta en nuestra versión optimizada del ejemplo anterior. arrastra también, desde el grupo hTML, un botón hTML normal. en su atributo onclick asígnale el código Javascript “Mos- trarhora();”, que enseguida definiremos.
el código final debería tener este aspecto:
Figura 3.- código hTMl de nuestro ejemplo optimizado
a excepción del ScriptManager no estamos utilizando controles de servidor, pero en cualquier caso daría igual porque, como veremos, ya no será necesario enviar el
ViewState ni otros elementos de formulario que hubiese en la página asPX.
en el archivo Code Beside de la página (el .vb o .cs correspondiente) vamos a definir una sencilla función llamada DameHora() que devolverá una cadena con la hora actual en el servidor:
<WebMethod()> _
Public Shared Function DameHora() As String Return DateTime.Now.ToLongTimeString() End Function
al igual que si de un miembro de un servicio Web asMX se tratara decoramos este método con un atributo WebMethod. esto es indispensable para llamarlo desde el lado cliente.
otra cuestión importante a tener en cuenta es que el método que definamos para ser llamado desde el cliente debe ser un método estático (o Shared en visual Basic). el motivo es que así no será necesario instanciar la página, lo que provocaría la misma carga que en el caso anterior al reproducir el árbol de controles, etc...
el último detalle que nos queda es asignar a True la propiedad EnablePageMe- thods del ScriptManager, que por defecto contiene un False.
Nota:
esta propiedad hay que establecerla sobre el verdadero ScriptManager que vayamos a uti- lizar. No se puede establecer en un ScriptManagerProxy por lo que si el nuestro está en un Master Page debemos marcarlo en ésta directamente y quedará habilitado para todas las páginas que la usen.
cuando se cree el código hTML final resultante de ejecutar la página, la pro- piedad EnablePageMethods hará que se genere automáticamente en el navegador el código Javascript necesario para llamar al método de la página. De hecho la llamada en Javascript será tan directa y fácil como escribir:
PageMethods.NombreMetodo
siendo NombreMetodo el nombre de alguno de los métodos de página que hayamos definido.
a este método de Javascript se le pasan dos argumentos: la función que se usará para recibir los resultados de la llamada, y la función a la que se llamará si se ha producido algún error.
con estas premisas, todo el código Javascript que necesitaremos escribir en el navegador será el siguiente:
<script language=”javascript” type=”text/javascript”> <!-- function MostrarHora() { PageMethods.DameHora(finLlamada, gestorErrores); } function finLlamada(resultado) { $get(“divHora”).innerHTML = resultado; } function gestorErrores(excepcion) {
$get(“divHora”).innerHTML = “Error en la llamada: “ + excepcion.get_message();
} // --> </script>
recuerda que la función MostrarHora es la que definimos para ser llamada cuando se pulse en el botón.
La función $get() es una extensión global al lenguaje Javascript de las muchas que define asP.NeT aJaX y que nos permite acelerar la escritura de código. en este caso $get es equivalente a llamar al método estándar del DoM, document.
getElementById, es decir, devuelve una referencia al elemento hTML cuyo nombre
le pasemos como parámetro. en el ejemplo nos devuelve una referencia a la capa
divHora de la página. con su propiedad innerHTML podemos introducir el hTML
que necesitemos en su interior, en este caso la hora o el mensaje de error según lo que ocurra.
ejecuta la nueva página y pulsa el botón de actualizar la hora del servidor. verás como de inmediato se muestra dentro de la capa en color rojo y funciona tan bien como la versión anterior.
en apariencia no hemos ganado gran cosa puesto que todo parece ir igual de bien que en el ejemplo precedente. como antes, vamos a analizar las peticiones al servidor
para ver qué información estamos intercambiando. si capturamos con Fiddler la petición generada por el método de página veremos el resultado de la figura 4.
Figura 4.- contenidos de la llamada al servidor con un método de página ¡ahora sí que hemos optimizado el trabajo! La petición inicial ocupa 0 bytes, o sea va vacía porque no hay dato alguno que enviar. La respuesta nos devuelve en este caso el resultado de ejecutar el método en el servidor, codificado en formato JsoN, listo para ser usado desde Javascript. su tamaño: 16 bytes. Y eso porque hay 8 bytes extra que se añaden a todas las respuestas debido a la definición del objeto JsoN devuelto. si el resultado fuera un dato más largo seguirían siendo sólo 8 bytes más y su importancia relativa sería menor aún.
es decir, hemos afinado al máximo el trasiego de información entre cliente y servidor, así como el código que ha de ejecutarse en el servidor, ya que no hay sobrecarga alguna por la ejecución de la página.
Las ganancias de tamaño y rendimiento son mucho más espectaculares aún en páginas más grandes (reales) con más controles.
si vemos el código fuente de la página generada podremos analizar con detalle el código Javascript autogenerado por el ScriptManager para conseguir toda esta funcionalidad. en la figura 5 se puede ver un fragmento del mismo.
Figura 5.- código autogenerado para habilitar los métodos de página es evidente que para ciertos casos esta técnica ofrece grandes ventajas.
2.- llAMAdAS A SErvicioS WEb
La técnica anterior está bien para trabajar dentro del ámbito de una misma página, pero presenta algunas limitaciones.
La más importante de ellas es que nos dificulta la reutilización del código, ya que los métodos están atados a una página concreta. si necesitamos utilizarlo en más de una página del sitio nos veremos obligados a definir otros tantos métodos estáticos de página.
otra limitación es que si usamos Master Pages en nuestro desarrollo y éstas son las que contienen el ScriptManager tendremos que habilitar la propiedad EnablePa-
geMethods en éste, sea necesario o no para cada una de las páginas. ello provocará
que se genere código Javascript para llamar a métodos de página que es innecesario en muchas de nuestras asPX, ya que no los utilizarán.
Una evolución mejorada de lo anterior es la capacidad del ScriptManager para habilitar las llamadas a servicios Web desde Javascript. ello nos permite tener en una única ubicación común todo el código reutilizable que vamos a llamar desde el navegador, eliminando la primera de las limitaciones anteriores. además se puede habilitar selectivamente el acceso a estos servicios desde el control ScriptMana-
gerProxy, por lo que sólo generaremos código Javascript extra en las páginas que