Vamos a suponer que tenemos un cliente de damas. El cliente es tonto para pintar, siempre pintará el estado del juego y esta lógica nunca se actualizará. En pantalla se pintará el tablero y una superposición de las opciones del jugador después de que éste haya seleccionado una pieza.
Cuando el usuario selecciona una ficha en el tablero se genera un evento que se procesará mediante una entidad representada por un script que puede cambiar en tiempo de ejecución. Normalmente este script formará parte de la configuración del juego, bien sea de la aplicación o de la partida en curso (se podría jugar a las damas inglesas con la misma interfaz pero distinta configuración). Si la ficha está bloqueada no se cambiaría la interfaz. Si no estuviera bloqueada, el script podría activar distintas opciones a mostrar en pantalla y pedir un repintado.
Esta parte está un poco borrosa y sin definir. La entidad que ha resuelto el evento no pasa de ser un EventHandler normal y corriente de los de toda la vida, en ella no intervinen lógica de negocio, sólo presentación. La parte en la que cito “ficha bloqueada” sería lógica de negocio. Ahí entraría una acción que sería, por ejemplo, MoverFicha. La interfaz de las acciones permitirían al código que las llama unas entradas de “seguridad” o, más bien, de comprobación de la posibilidad de ejecución. Varios métodos ayudarían a esto. Un getOptions o algo así, podría, no sólo decir si es posible realizar esta acción sino realizar algún refresco en la vista añadiendo las opciones a un menú que se pueda pintar. En este caso de las damas, en una capa por encima del tablero que estaba pintado, podrían aparecer en sombreado dos fichas en los posibles lugares a los que se puede mover la actual. Si la ficha fuese una dama en las damas inglesas esas casillas serían hasta ocho en un movimiento simple en el que no coma… La configuración lo variaría todo.
Esta acción se convertiría en comando cuando se ejecute. Por ahora estamos en la posibilidad de que se ejecute. El usuario la podría cancelar, la tenemos en cola para un posible fin de turno, es la acción actual y el botón volver la puede deshacer. El usuario confirma, la acción se ejecuta y repintamos el modelo en pantalla con el nuevo tablero… Se ha hecho cambiar el proxy del modelo en el cliente. Incluso, con ser este un juego de damas y sólo podemos mover una ficha cada turno, se podría comunicar al servidor el fin de turno o desencadenar una acción que permita al usuario aceptar para finalizar su turno. Entonces se enviarán los datos al servidor para que se actualicen el resto de clientes.
Ese paso, el de actualizar el resto de clientes, se puede independizar de la arquitectura, del método usado, etc. Habría que ver si hacemos PULL o PUSH desde el terminal. Un límite de tiempo y refresco a petición del cliente sería lo más óptimo a mi entender.
En próximos capítulos, el milagro del remote scripting ^^
