en el ejemplo anterior hemos hecho que la página del servidor devuelva ciertos valores que en este caso tenían formato XML, pero que podrían tener perfectamente otra configuración distinta, como por ejemplo simples valores separados por comas. si bien esto puede ser suficiente en los casos más sencillos, en otras ocasiones necesitaremos manejar estructuras de datos más complejas.
Dado que hTTP es un protocolo basado en texto, el recurso al que llamemos en el servidor debe devolver siempre texto (o sea, no puede ser una imagen o un archivo binario, que para transferirse se codifican de una forma especial -Base64- para convertirlos en texto). este texto devuelto puede tener cualquier formato: texto plano, XML, código Javascript o incluso hTML. en este último caso podemos obtener desde el servidor un contenido hTML completo que se debe escribir en una zona de la página (por ejemplo dentro de un <DIv> o un <sPaN>). sin embargo la mayor parte de las veces lo que tendremos que procesar es alguna estructura de datos.
Ya hemos mencionado que la ‘X’ de aJaX significa XML, pues era el formato de moda a finales de los 90 y principios de los 2000 y se usaba para todo. como se demostró en nuestro sencillo ejemplo este formato no es necesariamente el que se va a devolver. De hecho hoy en día el XML se usa muy poco a la hora de representar los datos textuales devueltos desde el servidor en páginas aJaX.
el motivo de esto es principalmente que los datos representados con XML, si bien son ricos en estructura, hacen que el resultado devuelto ocupe mucho debido a las etiquetas de apertura y cierre de los diferentes nodos. Gracias al DoM es fácil procesar la información jerárquica que se representa mediante XML, aún así debería existir algún método más directo, más rápido y que ocupe menos ancho de banda.
como alternativa a XML surgió un nuevo formato programable llamado JsoN (pronunciado “yeison”) que lo reemplaza con mucha ventaja en la mayor parte de los casos. JsoN es el acrónimo de JavaScript Object Notation, y como su propio nombre indica permite representar objetos (en realidad estructuras complejas) en forma de código Javascript que luego podemos evaluar.
JsoN tiene varias ventajas sobre XML, a saber: ocupa mucho menos al transmitirlo por la red. 1.
el acceso en el navegador a los elementos de datos representados es directo y 2.
sin necesidad de procesamiento farragoso usando el DoM o expresiones regu- lares, ya que se trata directamente de Javascript que se puede interpretar. Los datos pueden ir colocados en cualquier posición.
3.
<cliente> <nombre>José Manuel</nombre> <apellidos>Alarcón Aguín</apellidos> <empresa>Krasis</empresa> <telefono>902 876 475</telefono> <edad>37</edad> </persona>
ahora consideremos la misma representación en JsoN:
{
“nombre” : “José Manuel”, “apellidos” : “Alarcón Aguín”, “empresa” : “Krasis”,
“telefono” : “902 876 475”, “edad” : 37
}
crearlo es muy fácil pues es sintaxis Javascript normal. en www.json.org es posible encontrar una explicación completa de esta notación. La Wikipedia también tiene una información muy completa sobre ello.
como se puede comprobar ocupa menos que el XML equivalente, es igual o incluso más fácil de leer que éste, y permite usar datos nativos y no sólo cadenas para representar los valores. en estructuras de datos más complejas se puede apreciar más todavía el ahorro de datos que implica.
De todos modos lo más espectacular de JsoN es lo fácil que resulta usarlo. Basta con escribir lo siguiente:
var cliente = eval(res);
siendo ‘res’ el nombre de la variable que contiene el JsoN obtenido del servidor. es decir, lo único que hacemos es procesar la expresión JsoN. al hacerlo obtenemos en la variable ‘cliente’ un objeto cuyas propiedades son los datos que queremos manejar. De este modo lo único que tenemos que hacer para leerlos es escribir directamente expresiones como esta:
alert(“El nombre de la empresa es “ + cliente.empresa);
Más fácil imposible. Nada de recorrer una jerarquía XML con el DoM o ir buscando nodo a nodo en el contenido. se convierte en Javascript puro y utilizable nada más llegar desde el servidor.
el uso de JsoN como formato de intercambio sólo tiene dos problemas aparentes. el primero de ellos es el más obvio: generar XML con c# o vB.NeT es muy fácil pero generar JsoN ha requerido tradicionalmente un cierto trabajo por nuestra parte. Para evitárnoslo las últimas versiones de .NeT (3.5 o superior) incluyen la posibilidad
de que los servicios Web y WcF (Windows Communication Foundation) generen sus resultados directamente en JsoN. existen además bibliotecas especializadas en generar JsoN si estamos interesados en hacerlo de manera manual. Por ejemplo, una muy famosa es Jayrock (http://jayrock.berlios.de) que permite convertir objetos .NeT directamente a su representación JsoN.
el otro problema es tal vez menos evidente pero más importante: la seguridad. Dado que se usa una expresión ‘eval’ para convertir el texto en objetos Javascript podría utilizarse de manera malintencionada para inyectar código peligroso en la página al efectuar la evaluación. Para evitarnos este peligro con código en el que no confiamos, en JsoN.org tenemos un script (http://www.json.org/json.js) que extiende las cadenas de Javascript para convertirlas a JsoN verificando la sintaxis y evitando todo aquello que no sean datos. si incluimos este script en nuestra página en lugar de utilizar ‘eval’ podemos escribir:
var cliente = res.parseJSON();
para obtener el mismo resultado.
además nos ofrece la funcionalidad inversa de la siguiente manera:
var miCadena = cliente.toJSONString();
esto nos puede servir para enviar datos JsoN al servidor, para almacenar un objeto en una cookie, etc...
6.- EN rESuMEN
en este capítulo hemos aprendido los fundamentos de aJaX así como los principales problemas que nos podemos encontrar al utilizarlo. La comprensión de todo ello nos va a resultar útil aunque no usemos estas técnicas de “bajo nivel” sino que recurramos a un kit especializado como asP.NeT aJaX, o cualquiera de las múltiples bibliotecas de Javascript con soporte aJaX existentes en el mercado.
Lo habitual será que siempre implementemos características aJaX en nuestras páginas usando alguna biblioteca especializada. en el mundo Microsoft emplearás con toda seguridad la parte cliente de asP.NeT aJaX, así como la biblioteca de código abierto JQuery, que se soporta oficialmente a partir de visual studio 2010.
en el próximo capítulo vamos a estudiar las principales características de asP.NeT aJaX en el lado de servidor, que se traducen en mejoras en el lado del cliente.
25 como hemos visto en el capítulo anterior, aJaX es un gran aliado a la hora de mejorar la usabilidad y la capacidad de respuesta de la interfaz de nuestra aplicación Web. Las técnicas aJaX nos evitan tener que refrescar la página completa cada vez que se genere un evento de servidor, lanzando las peticiones en segundo plano y refrescando sólo las partes de la interfaz que sean apropiadas en cada caso.
conseguir todo esto directamente con nuestro propio código Javascript en el navegador puede convertirse en una tarea tediosa, que necesita bastante trabajo y es propensa a errores. Para evitarnos estos problemas y facilitarnos la tarea asP.NeT incluye una biblioteca especializada en creación de aplicaciones aJaX. Microsoft, en un alarde originalidad, llamó a esta biblioteca asP.NeT aJaX. su nombre anterior, cuando estaba todavía en versión Beta, era “atlas” y la verdad es que a casi todo el mundo le gustaba más :-)
La biblioteca de aJaX se divide en dos partes claramente diferenciadas pero que trabajan de manera conjunta para dotarnos de funcionalidad:
· Biblioteca de servidor: contiene un conjunto de controles Web que abstraen de manera muy efectiva las tareas que deberíamos hacer normalmente en el cliente. Generan todo el código necesario para gestionar de manera asíncrona las llamadas al servidor y las actualizaciones. Los dos más importantes son el control ScriptMa- nager y el UpdatePanel. en la figura se pueden observar los controles dentro del cuadro de herramientas de visual studio.