Aunque Mariscal no se lo acaba de creer, DimeHoteles.com utiliza AJAX en algunas de sus partes. Utilizar AJAX con JSF es algo relativamente fácil: creamos un PhaseListener que intercepte las llamadas y actuamos en consecuencia (el javascript y demás es AJAX en si mismo, nada que ver con JSF). En este post no pretende a usar AJAX con JSF, simplemente comentar un error tonto que puede hacerte perder el tiempo: ¿por qué si envío la respuesta correctamente no puedo procesarla como XML?.
Como sabreis, al recibir la respuesta en nuestra rutina JavaScript, podemos tratarla como XML o como HTML. Si la tratamos como HTML (req.responseText), sólo tendremos que añadirlo a la región de la página que queramos modificar. Pero sin embargo, al tratarlo como XML (req.responseXML), podemos tener la tentación de olvidar una de los partes obligatorios de todo documento XML, su cabecera.
Podemos estar tentados a pensar que poniendo el content-type, el charset y el encoding a nuestra respuesta (a través del objeto response del API de Servlets), nuestro documento será tratado correctamente al procesar el XML. Más aún si también solemos enviar la respuesta en HTML directamente. Craso error. Debemos considerar que esa información es sólo para el envío, y que una vez en el navegador del cliente, se trata como un documento XML tal cual. Y como tal, tiene que tener su propia cabecera XML (), porque de lo contrario nos dará un error al parsearlo, obteniendo un precioso null al hacer req.responseXML.
Efectivamente, ademas debes poner el Content-type, en caso de que no lo ponga directamente el Servidor Web.
¿ Has probado a utilizar XML y un filtro de compresion ?
Yo todavia no lo he hecho y me encantaria conocer la respuesta sin tener que probar.
Este me le conozco….
En una aplicación X tenemos que comunicarnos con el host del banco Y que nos proporciono una “librería” (dos clases guarras en un .jar) para acceder a estas funciones del host.
Pues bien, todos sus métodos devuelven como resultado un XML, lo gracioso es que a veces viene con cabecera y a veces sin cabecera (todavía ando intrigado por el patron de comportamiento, parece que tengan un random para ponerlo), como se niegan a cambiarlo porque dicen que todos sus XML cumplen con el DTD que nos enviarón nos toco hacer una bonita chapuza para comprobar si el xml tiene o no cabecera “a mano” y si no tiene ponersela para pasarselo al parser.
PD: Si alguien quiere pasar una tarde de risas que me lo comente que les mando el DTD que también tiene lo suyo… en dos palabras im-presionante.
Ya, pues, danos el DTD. Quedé intrigado….
Quise decir si viene el Content-type y el Content-lenght.
Lo otro es una pregunta, habeis probado a devolver el XML con Content-Encondig gzip, si la respuesta es positiva. ¿ Funciona ? ¿ Porcentaje ?
Pues no, no he probado con GZIP. Algún día quizás lo haga, pero ahora mismo no lo hemos hecho.
Pues me ha sido muy util este post pues llevaba un dia entero preguntandome porque el responseXML me devolvia un null como una casa. en el servlet me faltaba el response.setHeader(”Cache-Control”, “no-cache”);
Gracias