Hola gente,
Estuve algunos d�as ocupado con otras cosas, y el SWT/ST2JS/etc no
avanzaron mucho. Ahora estoy por volver a la actividad, y como el
movimiento se demuestra andando les comento en que estado estamos.
Sigo detenido en el punto MVC-Distribuido. Si bajan las �ltimas
versiones, ver�n que est� funcionando relativamente bien.
La versi�n actual prueba (creo, decidan ustedes mismos) que es posible
hacer una aplicaci�n MVC donde el M(odel) est� en el server (Smalltalk)
y el V(iew)/C(ontroller) est� en el cliente (Browser de Internet). Para
lograr tiempos de respuesta adecuados, algunas optimizaciones ya fueron
hechas y funcionan bastante bien.
Para acelerar los tiempos de respuesta, b�sicamente hay que reducir la
cantidad de requests desde los clientes.
Mensajes Asincr�nicos/Cola de mensajes asincr�nicos:
----------------------------------------------------
En una aplicaci�n t�pica MVC, el View se conecta a MUCHOS eventos del
modelo. Cada suscripci�n implica un env�o de mensaje. Si el Modelo
est� remoto, eso implica 1 request por internet. Imaginemos un simple
objeto de clase Cliente, con algunos aspectos como #nombre, #apellido,
#fechaDeNacimiento y #dni. Para crear una Vista con esos aspectos, el
View/Controller deber� suscribirse a los eventos de nombre #nombre,
#apellido, #fechaDeNacimiento y #dni... es decir: 4 requests.
Si a eso le sumamos que, antes de suscribirse hay que hacer un request
para pedir una referencia remota, tendremos que hacer N+1 requests para
crear una vista sobre un objeto con N aspectos.
El caso empeora cuando cargamos un objeto en la vista y descargamos
otros. En ese caso necesitamos N+1 requests para el objeto nuevo
(siendo N la cantidad de aspectos del objeto nuevo) y M requests para
desuscribirse de los eventos del objeto viejo (siendo M la cantidad de
aspectos del objeto viejo).
Por supuesto eso matar�a la velocidad del cliente.
Sin embargo encontr� una forma de optimizaci�n que funciona muy bien, y
logra resolver el caso dado (con o sin objeto viejo) haciendo SIEMPRE 2
requests: 1 para obtener la referencia remota al objeto nuevo, y 1 para
hacer (en batch) TODAS las desuscripciones y suscripciones.
El truco consiste en lo siguiente:
- Cuando hacemos un env�o de mensaje al #serverSide, y no
necesitamos un valor de respuesta, podemos hacer el env�o
asincr�nico. Para poder tomar ventaja de esto, el proxy
generado del ServerApplication incluye 2 m�todos por cada m�todo
del ServerApplication, uno para invocarlo sincr�nicamente y otro
para hacer as�ncrono.
- El framework permite encolar muchos env�os de mensajes
asincr�nicos en 1 s�lo pedido, simplemente haciendo algo como:
aRemoteModel. "Referencia remote obtenid"
self isolatedAsynchronousRPCMethods: [
mainPanel clearWidgets. "Limpia los widgets viejos, causando que el
browser se desconecte de los eventos al modelo anterior."
mainPanel addWidget: aRemoteModel defaultView. "Crea la nueva vista al
nuevo modelo, causando la conexi�n a los eventos del modelo nuevo."
].
(Ver senders/implementors de #isolatedAsynchronousRPCMethods:)
Eventos extendidos:
-------------------
Otro patr�n t�pico de las aplicaciones MVC es que el View env�e un
mensaje (por ejemplo el mensaje #nombre) cuando se entera que el modelo
cambi� (por estar suscripto al evento de nombre #nombre). Si tenemos en
cuenta que el Modelo est� en el servidor, y que las Vistas/Controladores
est�n en los browsers, veremos que cuando el modelo cambia (y el evento
se propaga a los browsers, usando la conexi�n Comet) todas las vistas
enviar�n un mensaje al Server para obtener el nuevo valor del modelo.
Para optimizar ese caso, expand� (levemente) el mecanismo de eventos.
As� se suscribe un Aspecto (SWTAspect) al modelo.
self model
when: self eventName
send: #modelChanged:
to: self
withResultsOfSelectors: {self getter}
La clave est� en la �ltima parte del mensaje: "withResultsOfSelectors:
{self getter}". Cuando ocurre un evento de nombre "self eventName", el
modelo enviar� el mensaje "#modelChanged:" a "self", INCLUYENDO en el
env�o el resultado de enviar el mensaje "self getter" al modelo.
Con ese "truco", el evento se propaga con la informaci�n extra necesaria
evitando que los clientes (browsers) tengan que hacer un pedido.
�C�mo sigue el trabajo? --> Hay que lograr que un usuario del framework
no tenga que manejar a mano la complejidad inherente a tener un MVC
distribuido. Para eso el framework debe auto-optimizarse (usando estos
trucos, y otros que se nos ocurran) desde el uso normal. Este objetivo
est�, en parte, tambi�n resuelto: Si uno se limita a usar los Aspects
entregados por SWTModel para crear las vistas, tendremos todas estar
optimizaciones ya hechas.
Entonces ahora toca encontrar una forma de describir los modelos, que
sea Smalltalk-way, pero que tenga el nivel de abstracci�n correcto para
poder meter optimizaciones por debajo. En la versi�n actual la
sobre-cargada-de-responsabilidades clase SWTAspect, y la clase
SWTRemoteModel logran esconder la complejidad... pero, como les dije,
SWTAspect es casi un engendro de mezclas de responsabilidades.
Despu�s de esta s�bana de email, les dejo estas preguntas:
- �Qu� framework de hacer UIs (de Smalltalk u otro lenguaje) les
parece m�s poderoso?
- �Qu� tipo de framework permitir�a crear vistas autom�ticas?
-- �Cuanto de dif�cil es tunear a mano esas vistas autom�ticas?
- �Vieron el NakedObjects (http://nakedobjects.org/)? �Qu� les
parece?
Saludos,
-- Diego
--
==========================================
Diego Gomez Deck
------------------------------------------
http://diegogomezdeck.blogspot.com/
http://smalltalk.consultar.com/
==========================================
--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque est� 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�e un mensaje a [EMAIL PROTECTED]
Para obtener m�s opciones, visita este grupo en
http://groups-beta.google.com/group/clubSmalltalk?hl=es.
-~----------~----~----~----~------~----~------~--~---
