Hola Andrés!
Con respecto al volumen, probablemente en la arquitectura de las
redes de hoy tenga un límite, pero pensando que ya se están evaluando las
redes varias veces más rápidas que las de hoy en día, no habría problema en
desarrollar este tipo de framework. Está pensado para aplicaciones web 2.0,
que hoy, se resuelven con flash, applets y AJAX, haciendo que sea más
complicado que nunca desarrollar. Creo que este tipo de aplicaciones (que no
todos entienden[1]) son las que Smalltalk nos ayuda a ofrecer. Una vez más,
dando ese paso que en la tecnología tradicional es casi imposible lograr por
una sola persona.
En cuanto a lo que están haciendo no logré entender bien, pero creo
que deberías pegarle un vistazo al ST2JS. Resuelve cosas no tan triviales.
El framework en total tiene un trabajo de más de 2 años por parte de Diego,
y tiene resueltas cosas complejas. Supongo que para tu desarrollo te será de
utilidad el pegarle un vistazo.
Saludos,
Hernán.-
[1] Porque ni siquiera Ruby on rails es popular en las empresas hoy en día
para el desarrollo de aplicaciones web, que un clon de Seaside sobre Ruby.
-----Mensaje original-----
De: [email protected] [mailto:[EMAIL PROTECTED]
En nombre de Andres Fortier
Enviado el: lunes, 28 de abril de 2008 12:02 p.m.
Para: [email protected]
Asunto: [clubSmalltalk] Re: Nuevo Framework para desarrollo Web sobre
Smalltalk (Squeak)
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.
-~----------~----~----~----~------~----~------~--~---
