Hola gente,
[snip]
> Volviendo
> a SWT (y poniéndome en abogado del diablo un rato :))
> hay algunas cosas que te quería preguntar:
>
> 1. De entrada suena medio chocante tener que llevarme
> todo el código de las clases ST a javascript. Tenés
> algún tipo de comparación contra otros fwks respecto de
> lo "pesada" que termina siendo la página? Al mismo
> tiempo, tienen políticas de partición de scripts para
> que el browser cachee o hacen siempre todo inline en la
> página?
En SWTClientApplication class>>includeEmbeddedJavascript se puede
definir si querés el JS "incluido" o en files diferentes.
En un entorno de producción, se podría generar los .JS en modo "batch"
desde el Smalltalk y servirlos desde un Apache (con todo el tema de los
caches bien configurados). Además, haciéndolo así, se podría onfuscar,
comprimir, etc los JS.
> 2. Ya hay mucho laburo hecho en widgets y efectos
> bonitos para las páginas (YUI, scriptaculous, etc).
Y el SWT también. Tenemos un lindo juego de widgets y animaciones todo
escrito en Smalltalk. Tenemos un mecanismo de #stepping en los widgets
(a la Morphic), etc.
> Cuentan con alguna forma de "hablar" con esas librerías
> existentes?
Sip, en el ST2JS hay varias formas de escribir código JS "literalmente".
Fijate senders de #jsLiteral:, #jsLiteral:inSmalltalk:, #jsSet:to:,
#jsGet:, #jsPerform:, #jsNew:, etc, etc.
En SWTOpenLayers hay un (todavía no terminado) ejemplo de como envolver
una librería JS (en este caso OpenLayers) con objetos SWT. También está
la clase SWTSoundManager que envuelve la librería soundmanager.
> 3. Cómo deciden que parte se traduce a javascirpt y que
> parte no? O sea, suponete que yo hago una vista HTML
> que tiene un modelo, el cual va a residir en el server.
> El fwk sabe que tiene que traducir el código de la
> vista y no el del modelo? Cómo configuran esto?
Para hacer una aplicación SWT hay que crear 2 clases:
NombreAplicacionServerApplication y NombreAplicacionClientApplication.
La clase NombreAplicacionServerApplication debe ser herencia de
SWTServerApplication, y la clase NombreAplicacionClientApplication debe
ser herencia de SWTClientApplication.
Todo lo escrito en XXXClientApplication se traduce a JS, se transfiere
al browser, se instancia (en el browser) y se conecta con la parte
"server".
Del lado del "server", se crea una instancia de XXXServerApplication por
usuario conectado y se conecta con su contraparte cliente.
Desde el XXXServerApplication se pueden ejecutar métodos del
"client-side" con:
self clientSide foo.
Y, del lado del cliente, se pueden ejecutar método del "server-side"
con:
self serverSide bar.
Sobre ese mecanismo "básico" tenemos escrito un MVC con un
mini-framework de Aspectos (para definir las "partes" de los modelos)
que permite que el Model resida en el Server, y el View/Controller en
los browsers de internet.
Para hacer objetos más "básicos" (digamos que estén fuera del SWT), hay
que heredar de S2SObject.
En la categoría de método "translation" de la clase S2STranslator podés
encontrar método para generar JS desde 1 método, desde una clase
completa, etc.
Creo que en otro email preguntabas por el tamaño de una aplicación SWT.
En el juego de cartas (que es la aplicación más grande que tenemos
escrita hasta ahora) el html con todo el JS ronda los 460Kb. (Ese
fuente no está ni comprimido, ni onfuscado, ni nada).
> Bueno, de mas está decir que el trabajo me parece muy
> interesante.
Me alegra!
> Saludos,
> andrés
Saludos,
-- Diego
--~--~---------~--~----~------------~-------~--~----~
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.
-~----------~----~----~----~------~----~------~--~---
