Que cagada no poder reemplazar (por cuestiones comerciales obvias, no tenicas) JavaScript por Smalltalk en el cliente asi queda todo uniforme no?
2008/4/29 Andres Fortier <[EMAIL PROTECTED]>: > > 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. -~----------~----~----~----~------~----~------~--~---
