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