Introducción
En este framework, basado en la arquitectura Comet y con un mini-Smalltalk en los navegadores sobre Javascript, tenemos dos clases principales para hacer un aplicativo, SWTClientApplication y SWTServerApplication. La primera es la clase que modela la parte cliente, que corre en el navegador y sobre Javascript, y de la cual heredará nuestra clase que será la responsable de presentar la interfaz al usuario; la segunda, es la clase en el servidor, que corre en Smalltalk, y de la cual se heredará para darle comportamiento al aplicativo controlando al cliente o los clientes. El framework también nos provee de un esquema de Model-View-Controller distribuido. Vamos a realizar dos simples ejemplos para mostrar el uso de este framework.
Ejemplos de uso
Vamos a hacer dos aplicaciones muy sencillas, la primera es un ejemplo de como usar el framework en una aplicación donde el servidor y cliente solo se comunican en forma básica, y en la segunda, es una adaptación de la primera pero usando algunas funcionalidades más.
Ping/Pong
La idea detrás de este aplicativo es que el cliente envíe un «ping» al servidor, y este le responda con un «pong». Es muy simple y vamos a explorar las cualidades más básicas del framework al escribir esta aplicación.
Creando nuestras clases
Para comenzar vamos a crear nuestra clase cliente, heredando de SWTClientApplication y a la cual vamos a denominar SWTPingPongClientApplication.
Para el cliente:
SWTClientApplication subclass: #SWTPingPongClientApplication instanceVariableNames: »
classVariableNames: »
poolDictionaries: »
category: ‘SWT-Examples’
Para el server:
SWTServerApplication subclass: #SWTPingPongServerApplication instanceVariableNames: »
classVariableNames: »
poolDictionaries: »
category: ‘SWT-Examples’
Dándole un nombre al aplicativo
Con las clases definidas, vamos a darle un nombre a nuestro aplicativo, esto lo hacemos redefiniendo un mensaje de clase en la parte server a través de #applicationName, nuestro aplicativo se llamará «Ping/Pong».
El principal propósito de esto, es que el framework nos presenta una lista de aplicativos a ejecutar por defecto en el navegador, si este lo apuntamos a la dirección por defecto http://127.0.0.1:2222, y el título que usa para hacer la presentación de cada aplicativo, es este mensaje.
SWTPingPongClientApplication class>>applicationName ^ ‘Ping Pong’
Poniendo los controles web
Como mencionamos anteriormente, la parte cliente es la responsable de la presentación en el navegador, por lo tanto, vamos a crear los elementos necesarios. Para realizar esto, tenemos toda una jerarquía de Widgets o controles web, que se clasifican a partir de SWTWidget.
El framework nos provee de ciertos mensajes que debemos definir, unos de estos es #initializeWidgets. En este mensaje se define la construcción de la página web, armando los controles que irán, como se componen y que eventos y propiedades tienen. Para nuestro caso, lo que queremos que vea el usuario es un titulo con el nombre de nuestro aplicativo y vamos a colocar un botón donde el usuario envia el «Ping» al servidor.
SWTPingPongClientApplication>>initializeWidgets «Initialize the receiver’s widgets»
| root |
root := self rootWidget.
root addWidget: (SWTHeader level: 2 contents: self class applicationName).
root addWidget: (SWTButton caption: ‘server ping’ onClick: [:event | self serverSide ping]).
Como podemos apreciar en el método anterior, lo hacemos es crear un control raíz, o root widget, y a partir de este armamos nuestra página. En este caso, hemos agregado primero un título de nivel 2, o como se lo conoce en HTML, un tag H2 con el nombre de nuestra aplicación usando el método más arriba definido. Por último, se agregó un botón con la leyenda «server ping», y que, al ser clickeado envia al servidor el mensaje #ping.
Implementando el ping en el servidor
Una vez hecha la parte cliente, vamos a implementar el mensaje #ping, que estamos enviando desde el navedor al presionar el botón. Desde el cliente, cuando enviamos #serverSide, nos retorna un objeto remoto a nuestra aplicación del lado del servidor. Es por ello, que vamos a implementar el comportamiento del «ping» en el server.
SWTPingPongServerApplication>>ping Transcript show: ‘ping!’; cr.
self clientSide pong.
Lo que hemos definido en el servidor, es una vez que recibimos el #ping, escribimos el mensaje en el Transcript de Smalltalk (es una ventana de salida de mensajes) y luego, le devolvemos un «pong» al cliente.
Como podemos apreciar, para enviar mensajes hacia un lado u otro usamos un mensaje, para obtener la parte cliente desde el servidor es #clientSide, y para obtener la parte del servidor desde el cliente es #serverSide. De forma tan simple, podemos enviar comunicación para un lado o para el otro a través del canal establecido por la arquitectura de Comet. Recordemos que el HTML es un protocolo asimétrico, es decir, solo la comunicación la establece el cliente, y el servidor se limita solo a contestar las peticiones. En la arquitectura comet que usa este framework, esa diferencia no existe, ya que la comunicación entre el cliente y el servidor no se corta. En HTML una vez que el servidor haya cumplido con las peticiones del cliente la comunicación se corta. En Comet el servidor también puede enviar información al cliente sin que este último la haya tenido que solicitar. Esto es muy útil en aplicativos como sitios de remate, salas de conversación o chat, sitios de la bolsa de valores, y para cualquier aplicativo web donde la información cambie en el servidor y los clientes no tengan que hacer las peticiones para mantenerse informados, sino que sean informados en el instante en que se producen los eventos en el servidor.
Implementando el pong en el cliente
Ahora, por último, nos falta implementar el mensaje #pong en el cliente, y lo que vamos a hacer, es que cuando lo reciba muestre un mensaje al usuario con la expresión «Pong!»
SWTPingPongClientApplication>>pong self inform: ‘pong!’
Probando el Ping/Pong
Para hacerlo, tenemos dos maneras, la primera es apuntando a nuestro navegador a la dirección: http://127.0.0.1:2222.
Allí nos presenta un listado de aplicativos que podemos usar, el nuestro, aparecerá listado con el nombre que le indicamos en el applicationName.
La otra forma, es directamente apuntando al aplicativo, en este caso: http://127.0.0.1:2222/SWTPingPongClientApplication.
Listo, ya estamos preparados para probar nuestro aplicativo. A continuación presentamos un screenshot del mismo.
Resumen del Ping/Pong
Hemos visto que se debe heredar de dos clases fundamentales del framework y que estas nos proveen unos mensajes que redefinimos para implementar nuestro comportamiento, esto en el cliente es el #applicationName y el #initializeWidgets.
En solo estos dos mensajes más un comportamiento básico de dos mensajes ping/pong hemos armado nuestro primer aplicativo. Como se vió también en este ejemplo, el framework nos da soporte para tener controles (SWTWidgets) y de comportamiento básico en la web, como lo es mostrar un mensaje (#inform:).
Echo Request / Echo Reply
Este aplicativo es muy parecido al ejemplo anterior, pero con la diferencia, que un echo envia un objeto como parámetro al server y este lo único que hace es reponderlo nuevamente. Es como un ping/pong, pero ahora, con una pelota.
Para realizarlo, vamos a repetir la misma secuencia que con el ejemplo anterior, pero esta vez, enviando un mensaje al servidor y este nos lo va a devolver.
Para el cliente:
SWTClientApplication subclass: #SWTEchoClientApplication instanceVariableNames: »
classVariableNames: »
poolDictionaries: »
category: ‘SWT-Examples’
Para el server:
SWTServerApplication subclass: #SWTEchoServerApplication instanceVariableNames: »
classVariableNames: »
poolDictionaries: »
category: ‘SWT-Examples’
Y le vamos a definir el nombre del aplicativo:
SWTEchoClientApplication class>>applicationName ^‘Echo!’
Poniendo los controles web
Vamos crear un titulo, un lugar donde poner un texto y al presionar el enter, enviará el texto al servidor.
initializeWidgets «Initialize the receiver’s widgets»
| root input |
root := self rootWidget.
input := SWTInputText contents: ».
input
onKeyPress: [:event | event keyCode = 13
ifTrue: [self serverSide echoMessage: event source contents]].
root
addWidget: (SWTHeader level: 2 contents: self class applicationName);
addWidget: (SWTText contents: ‘Ingrese un mensaje y presione enter para enviarlo al servidor: ‘);
addWidget: input
Lo que hemos hecho en este mensaje, es utilizar las propiedades que nos brinda el SWTInputText, al presionar una tecla, y si esta tecla es un enter (codificado como 13), se envia un mensaje al server (#echoMessage:), con un argumento, este no es más que el contenido del control que generó el evento. En este caso, ese contenido es el texto que ingresamos.
Ahora, vamos a definir, nuestro #echoMessage: en el servidor, que lo que hace, no es otra cosa que devolverlo al cliente de la siguiente manera:
SWTEchoServerApplication>>echoMessage: aMessage self clientSide echoMessage: aMessage
En el cliente, ahora necesitamos implementar nuestro mensaje #echoMessage:, que no hará otra cosa más que mostrar un cartel en el navegador con el mensaje.
SWTEchoClientApplication>>echoMessage: aMessage self inform: aMessage
Probando el Echo
Para hacerlo, como sabemos, hay dos maneras, pero vamos a usar la forma directa: http://127.0.0.1:2222/SWTEchoClientApplication.
Y el resultado es:
Como podemos apreciar, enviamos un mensaje, le dimos enter, y el cartel nos muestra que escribimos.
Resumen del Echo
En este aplicativo, hemos aplicado lo mismo que para el Ping/Pong, pero con la diferencia que usamos un nuevo control, y sus eventos para generar un ping/pong pero con un mensaje que nosotros indicamos.
Conclusiones
Estos dos mini-aplicativos que presentamos no tenían otra intención que hacer un pequeño uso del framework SWT.
Las aplicaciones que se pueden lograr en esta plataforma son mucho más complejas y ricas. La idea que hay detrás es abstraerse, por medio del framework, de la cantidad de complicaciones que genera un aplicativo web y enfocarse en la resolución adecuada de nuestro problema. Para ello SWT nos provee del lado cliente un mini-Smalltalk hecho sobre Javascript, hay comunicación constante entre servidor y cliente a través de la arquitectura de Comet, hay un framework de Model-View-Controller distribuido que nos permite hacer aplicaciones más desacopladas y optimizadas para funcionamiento sobre la red, y una capa de controles web, que podemos expandir hacia donde necesitemos. Como se puede apreciar, es mucho trabajo el que realiza el framework en aras de conseguir una abstracción adecuada para desarrollar aplicaciones más complejas sobre la web.
CEIBO 
Deja un comentario