Arena. Pantalla de edición general.

Ayuda para entender cómo funciona un panel de edición

Un panel de edición permite al usuario definir una nueva entidad o modificar la información de una entidad existente. Cada atributo que queremos que el usuario modifique/visualice tenemos que asociarlo con un control visual (widget).

En amarillo los packages que deberías definir vos. En blanco los que vienen con Arena. Nota: la interfaz Home<T> se renombró a Repo<T>.

Se muestran en el diagrama el comportamiento más relevante de cada objeto.

Dialog implementa la interfaz TaskWindow, TransactionalDialog<T> implementa la interfaz TaskOwner: se ocultaron estas interfaces para conservar el diagrama simple y legible (el lector puede investigar al respecto).

  • Si te interesa que tu formulario sea modal (por lo general está bien que sea así) tu panel debería extender de Dialog<T>.
  • Si querés que además de ser modal el formulario trabaje dentro de una transacción, tu panel debería extender de TransactionalDialog<T>.
  • T es
    • un objeto de tu dominio (Socio en el caso del videoclub, Celular en el caso de los celulares). En el diagrama mostramos que T extiende de Entity (pero esto es opcional).
    • o podría ser un application model o view model, por ejemplo para encapsular el conocimiento del repo, o para ayudar en el caso de uso si es complejo
  • T es obviamente el model de tu vista, es el atributo "model" de la clase Window<T> (la clase madre de todas las ventanas de Arena):
  • El modelo de la vista debe notificar los cambios a sus interesados, esto se logra a través de la annotation @Observable. Si además querés que se mantenga la edición en una transacción, la annotation debe ser @TransactionalAndObservable.

Ejemplo: en la clase Celular (que es nuestro modelo de vista de ejemplo) escribimos

o bien usamos la annotation @TransactionalAndObservable. Recuerden hacer esto, o la vista no actualizará sus valores ante un cambio en el modelo (Arena igualmente tira un error).

  • La vista de edición define
    • en createMainTemplate, el título (opcional)
    • en createFormPanel, el layout y los controles que van a aparecer (cada control se bindea con un atributo del objeto de dominio a editar)
    • en addActions, las posibles acciones (que se implementan con botones Aceptar y Cancelar que bindean con métodos)
    • en executeTask, qué debería hacer el usuario en caso de Aceptar (en general, delegar a un repo, anteriormente home, la acción de agregar/modificar el objeto). En este método que definas es importante que llames al executeTask() de tu superclase (como última línea del método), para que se haga commit de la transacción y se active el circuito de notificaciones... O bien en el evento onAccept...

Y lo acompañamos con dos diagramas de secuencia que muestran:

1) cómo se crea el formulario

  • Al crearse el panel, también
  • se instancia el model (new Socio)
  • Luego se dispara el createContents(), que define
    • el layout
    • el panel de errores (que está arriba): aquí se van a mostrar errores propios del binding
    • el formulario donde van los controles
      • se instancian los textboxes, comboboxes, etc.
      • se bindean contra cada propiedad del modelo (que ya está instanciado)
    • por último van las acciones que el usuario puede disparar (la botonera)
      • el "aceptar", bindeado contra el método executeTask
      • opcionalmente podemos definir el cancelar, bindeado contra el método cancelTask

2) Lo que ocurre cuando el usuario ingresa los datos del socio y luego presiona el botón Aceptar:

  • Si se ingresa un valor en el campo nombre
    • lo escrito en el control TextBox dispara una notificación a los interesados
    • uno de los interesados es el modelo, esto se definió al bindear la propiedad "nombre" de un Socio con el valor del textbox
    • se dispara un setNombre pasando como argumento el valor del textbox al objeto Socio que es el modelo de la vista
    • a su vez, esto dispara notificaciones a la vista, pero hay un mecanismo inteligente que evita entrar en loop infinito
  • Al presionar el botón Aceptar
    • El model ya está actualizado (esto sucede conforme el usuario va ingresando la información por pantalla)
    • Se dispara la validación al model (el tipo T debe ser responsable de esto)