Hernán,
que tal? super interesante el trabajo.
Casualmente en este momento estoy trabajando sobre un
proyecto en Seaside que se toca en muchos puntos con lo
SWT. En si hay dos cosas con las que estaba jugando:
1. Envío de mensajes al cliente. La idea es que viajen
en forma de commands o como eventos, pero que el
cliente tenga la posibilidad de hacer algo en base a un
cambio en el server. Claramente el objetivo de todo
esto es lograr un MVC como la gente, donde la página
web + browser cumplen el rol de V/C. El problema a usar
cosas como Comet es que, por lo que llegué a ver, no
escala muy bien que digamos en términos de la cantidad
de clientes, por estar obligado a mantener un caño
abierto en el server por cada cliente. Te hago una
pregunta: hicieron pruebas con N clientes al mismo
tiempo (con N medianamente grande :))?.
2. Envío de mensajes javascript desde St. Todo comenzó
con un port de la API de google maps para seaside y ahí
surgió la necesidad de enviar mensajes al mapa. Una
opción posible en Seaside es embeber código javascript,
pero eso me resultaba un moco. Por otro lado no quería
tener que traducir todo el código St a javascript,
porque en realidad mi objetivo es un poco la inversa,
esto es, dado un objeto que ya existe en javascipt,
poder mandarle mensajes "a la Smalltalk". Ejemplo:
channel:=(html messageChannel
callback: [self showBar
ifTrue: [self map
enableGoogleBar]
ifFalse:[self map
disableGoogleMap].
].
y:
html checkbox
...
value: (self map isEnabled: anItemName);
onChange: channel.
Lo que sucede en este caso es que, al interpretar el
bloque de callback uso un BlockContext modificado que
captura en envío de un mensaje y, si el receptor está
registrado como objeto javascrip [*], traduce el envío
del mensaje y lo interpreta en la página. Lo
interesante es que en el ejemplo que puse no se traduce
todo el código compilado en forma estática, sino sólo
lo que se evalúa. De hecho, en este caso habría tres
mensajes para evaluar (asumiendo la rama del ifTrue):
self showBar (self no es un objeto javascript =>
ejecución normal)
aBool ifTue:[] ifFalse:[] (idem al anterior)
self map enableGoogleBar (el mapa si es un objeto
javascript, luego, aparte de enviar el mensaje en st se
genera algo de la pinta de
'google_map_3619.enableGoogleBar();' Esto luego se pasa
al channel, que no es mas que un div con un id
determinado el cual al refrescarse reinterpreta el script).
Hasta el momento el approach me resultó cómodo, aunque
le encuentro tres (potenciales) problemas:
1. Viendo el código uno no puede discernir si el objeto
es javascript o no. Esto puede ser bueno a nivel de
transparencia, pero confuso a la hora de debuggear.
2. El mismo bloque, ejecutado fuera de un
messageChannel es código St común y corriente.
Nuevamente, esto puede llegar a ser confuso.
3. Es posible que se generen mensajes en javascript de
gusto; ejemplo:
self map isGoogleBarEnabled
ifTrue: [self map enableGoogleBar]
ifFalse:[self map disableGoogleMap].
el código resultante es (asumiendo la rama del ifTrue):
google_map_3619.isEnabled();
google_map_3619.enableGoogleBar();
En este caso el primer mensaje es de gusto, pero en
principio no hay forma de saberlo. Se podría taggear a
los mensajes como "idempotentes" en términos de los
cambios que producen para evitar generar código de mas,
pero me parece una cosa muy compleja si el costo no es
mucho.
Igual el trabajo esta verde todavía (lo arranqué hace
una semana). Cualquier comentario es bienvenido.
Saludos,
Andrés
Hernán Galante escribió:
> Estimados,
> Tengo el agrado de invitarlos a probar y ver un nuevo
> framework para desarrollo web llamado Smalltalk Web Toolkit. El padre del
> mismo es un amigo conocido por todos, Diego Gomez Deck.
>
> ¿Cuáles son las cualidades de este nuevo framework?
> SWT rompe con la asimetría del protocolo HTTP, es decir, a través del hack
> Comet, ahora el servidor puede enviar contenido a los clientes conectados.
> Esto hace que se quiebre la barrera impuesta por el protocolo HTTP y el
> servidor no solamente pueda enviar contenido solo con un pedido del cliente,
> sino que a través de esto, en cualquier evento que se produzca en el
> servidor pueden ser informados los clientes (o los navegadores).
>
> ¿Cuál es su arquitectura?
> SWT consta de una parte cliente y una servidora. Es decir, el comportamiento
> del cliente lo desarrollamos íntegramente sobre Smalltalk. Gracias a un
> framework que traduce de Smalltalk a Javascript contamos con un
> mini-ambiente Smalltalk del lado del navegador. A partir de este esquema, se
> puede contar con un MVC (Model-View-Controller) distribuido. Este MVC logra
> ciertas optimizaciones para presevar el recurso más limitado, la red.
>
> ¿De donde obtengo más información?
> En el blog ceibo.wordpress.com podrán encontrar información de cómo usarlo,
> ejemplos, links a downloads, tutoriales, etc.
> Ceibo es un proyecto de barajas 3D sobre la web que usará SWT como
> arquitectura.
>
> Gracias!
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Has recibido este mensaje porque estás suscrito a Grupo "ClubSmalltalk" de
Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a [email protected]
Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED]
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/clubSmalltalk?hl=es.
-~----------~----~----~----~------~----~------~--~---
