Hernán,
creo que no me expliqué bien :(. Sobre el
tema de mandar mensajes del server al cliente ni
objeción no pasa tanto por la velocidad de la red o el
ancho de banda que consuma, sino por la necesidad que
el web server mantenga una conexión dedicada con cada
cliente; no estoy muy metido en el tema, pero si los
clientes tienen sesiones largas no me queda claro que
el web server no se quede sin recursos (sockets,
threads, etc) para atender clientes.
Respecto de ST2JS no fue mi intensión decir que era
trivial o inmaduro. A lo que apunto es que mi
problemática es un tanto distinta y de hecho lo veo
como cosas complementarias. Si no me equivoco, el
objetivo de ST2JS es tomar código Smalltalk y
traducirlo a javascript para que corra en el cliente
web. De hecho viendo el fuente de /St2jS - Test Runner/
se ve que codifica Point, Object, etc. El objetivo mío
es completamente distinto: dado un objeto que reside en
un javascript de la página (cuya definición vive en un
javascript externo), poder usarlo desde Smalltalk por
medio de callbacks. De todas formas me parece que se
pueden combinar ambos enfoques y hacer una solución que
implique escribir código 100% St y combinar objetos de
dominio St y widgets definidos por otros vendedores.
Igual hay que darle todavía muchas vueltas de rosca :).
Saludos,
Andrés
Hernán Galante escribió:
> 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.
-~----------~----~----~----~------~----~------~--~---
