Nos queda pendiente trabajar sobre dos temas que son comunes al diseñar UIs:
Esto se da en dos oportunidades en nuestro ABM modelo:
En el primero de los casos, la ventana de búsqueda no necesita pasar ninguna información a la pantalla de edición. Generamos un nuevo socio desde cero y luego se lo pasamos al repositorio o home que se encarga de agregarlo al repositorio. Entonces, ¿cómo me aseguro que el panel de búsqueda va a encontrar el socio/celular recientemente cargado?
Para editar una entidad sí necesitamos pasar la información de esa entidad del panel de búsqueda al de edición.
Y además tenemos que ver cómo nos encargamos de navegar de una pantalla a otra. Entonces:
Esto lo vemos implementado en el ejemplo de los celulares:
Entonces, ¿cómo manejamos la navegación? Hacemos el new de la vista y le enviamos el mensaje open. Tan sencillo como eso.
¿Y cómo pasamos información de una pantalla a otra? Para inyectar dependencias hay dos formas sencillas de hacerlo
Lo que le pasamos al constructor de la pantalla de edición es el modelo. Esto permite que se asigne como model y todos contentos.
Resumiendo:
Esta es una forma declarativa de trabajar:
Cuando enviamos el mensaje editor.open() estamos interrumpiendo el flujo de ejecución de la pantalla principal. Entonces toma el control la pantalla de edición que vimos en la primera clase.
Nos detenemos una vez más en la línea
porque plantea algo muy interesante: antes de llamar a la pantalla de edición (mucho antes de que el usuario vea esa pantalla y presione Aceptar) estamos guardando un comportamiento que tiene que ocurrir cuando esa edición termine exitosamente. Esa idea (diferir la ejecución de código) está presente en el Command Pattern [1], y la estamos implementando de esta manera.
Recordemos que cuando abrimos una pantalla de edición, necesitamos como modelo un socio, un celular, una entidad. Entonces, si el usuario se arrepiente y cancela la acción, la transacción no debe completarse. Una de las maneras de lograr esto es no enviar ningún mensaje al repositorio para que lo actualice. Es importante entender que cuando hacemos un new del objeto de dominio eso no tenga efecto colateral sobre el repositorio o home, de otra manera debemos deshacer ese new o la modificación propiamente dicha.