Implementación de un Panel de Edición en Arena 2.0

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 celeste los packages que deberías definir vos. En blanco los que vienen con Arena.
  • Si te interesa que tu formulario sea modal (por lo general está bien que sea así) tu panel debería extender de Dialog<T>, donde 
  • T es un objeto de tu dominio (Socio en el caso del videoclub, Celular en el caso de los celulares). T debe extender de ObservableObject, para que el modelo al actualizarse dispare notificaciones a sus vistas. 
  • T es obviamente del model de tu vista, es el atributo "model" de la clase Window<T> (la clase madre de todas las ventanas de Arena):
private T model;
  • No siempre será T un objeto de dominio, esto quizás ya lo sepas pero nunca está de más decirlo
  • El modelo de la vista debe notificar los cambios a sus interesados, esto como vimos anteriormente se logra en cada setter de alguna de estas maneras
    • enviando un mensaje firePropertyChange a sí mismo en base al valor anterior del atributo y el valor actual
    • o haciendo un setProperty que resuelve esto mismo en una línea
En versiones posteriores pueden reemplazar el setProperty por un setFieldValue.
Recuerden hacer esto, o la vista no actualizará sus valores ante un cambio en el modelo.
Los métodos firePropertyChange, setProperty/setFieldValue están definidos en ObservableObject, recuerden extender de esa clase.
  • La vista de edición define
    • en createMainTemplate, el título
    • 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 home la acción de agregar/modificar el objeto)
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 cancelarTask
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 (se va actualizando 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)
    • Se actualiza el model (crea o modifica dependiendo de la acción del usuario), el responsable de esto es el objeto home