Remote Scripting con DHTML

Luis Miguel Morillas morillas en posta.unizar.es
Mie Oct 20 14:18:45 CEST 2004


Mensaje citado por Chema Cortés <py en ch3m4.org>:

> Aunque no lo parezca, este mensaje tiene que ver con python :-P
> 
> Intento conseguir que la página web que ve el cliente se valide en el
> servidor 
> sin tener que recargar la página. Cuando se trabaja con formularios con un 
> gran número de campos resulta impracticable corregir en bloque todos los 
> errores. La idea es que el formulario esté ya (casi) validado antes de ser 
> enviado al servidor. Empleo DHTML (javascript) en el cliente y python en el 
> lado del servidor. 
> 
> Entre las técnicas posibles he estado mirándo tres vías:
> 
> 1) ActiveX, Flash, applets de java, pyXPCOM, SpiderMonkey, ...
> 
> Son tecnologías son muy específicas, bastante dependientes del navegador y de
> 
> que estén todo correctamente configurado para que funcione. (De spidermonkey
> 
> hablaré más tarde)
> 
> 
> 2) XMLRPC desde javascript
> 
> Requiere que el javascript del navegador pueda establecer conexiones 
> "XMLHttpRequest". En estos momentos sólo pueden hacerlo, más o menos, 
> explorer, mozilla y safari. Debido a problemas de seguridad (en explorer es 
> vía de entrada de virus) las conexiones quedan limitadas al mismo servidor 
> desde donde se visualiza la página. Para zope podría ser una buena técnica, 
> pero necesito que la validación se pueda hacer desde un servidor distinto al
> 
> que entrega la página. He decidido no seguir por esta vía.
> 
> 
> 3) Remote Scripting usando IFRAMEs ocultos creados dinámicamente
> 
> Es una técnica que puede considerarse como "truco" (no está apoyada en ningún
> 
> estándar), pero es mucho más compatible con todos los navegadores "modernos",
> 
> y da mucho juego desde el punto de vista DHTML.
> 
> El proceso sería el siguiente:
> 
> a) Un script de python en el servidor genera código dhtml (obtenido de una 
> plantilla, por ejemplo) y lo envía al cliente.
> 
> b) el cliente ejecuta el código dhtml y crea "al vuelo" un iframe oculto
> 
> c) como origen del iframe figura un script (en python) en el servidor cuya 
> ejecución genera más código dhtml 
> 
> d) el código dhtml del iframe se "incrusta" en el documento, pudiendo 
> manipular el árbol DOM sin tener que recargar la página
> 
> e) se responde a los diversos eventos, enviando datos al servidor desde 
> diversos elementos en un formulario
> 
> Suena muy complicado, pero cuando se ve en funcionamiento todo parece más 
> simple. Las pruebas las he hecho sin utilizar ninguna herramienta especial, 
> pero quiero probar con pyWeb en el lado del servidor. Toda la dificultad 
> radica en tener que generar el código javascript que accede al árbol DOM del
> 
> documento. Creo que con pyweb se puede incrustar javascript, pero necesitaría
> 
> algo tipo de wrapper similar a lo que hace Tkinter con Tcl/Tk, pero para 
> javascript.
> 
> Si nos centramos en mozilla/firefox (<http://wwwsearch.sf.net>), con python
> se 
> podría acceder al motor de javascript (llamado SpiderMonkey) con lo que, 
> desde el cliente, se podría manipular el árbol DOM del documento. Quizás 
> fuera más apropiado olvidarse de spidermonkey y utilizar directamente 
> PyXPCOM, pero es algo que no tengo pensado mirar más a fondo. Quisiera algo 
> que sirviera para cualquier navegador.
> 
> 
> En fin, qué os parece todo este rollo. ¿Creéis que me estoy complicando 
> demasiado?

jeje. Pues a mí me parece muy interesante, hasta me ha gustado la exposición
:-). Es un problema al que continuamente tenemos que atacar. En ASP.NET creo que
las herramientas generan de forma dinámica el javascript de las aplicaciones y a
cada cliente se le da (en teoría) el suyo. A mi me resulta difícl conjugar
prestaciones con universalidad de ejecución (no sé si se dice así, pero es el
final de la mañana :-P  ) Yo he optado por el javascript, teniendo en cuenta las
limitaciones que tú comentas.

-- 
Luis Miguel




Más información sobre la lista de distribución Python-es