Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎

Clase 3 - 28/3/2011

publicado a la‎(s)‎ 26 mar. 2011 17:26 por Nicolas Passerini   [ actualizado el 28 mar. 2012 8:13 por gisela decuzzi ]

Tercera clase: Validaciones y converters.


0. Algo más de arquitectura.

En los ejemplos que vamos a ver a partir de ahora, vamos a intentar hacer aplicaciones más "reales". Eso implica pensar en persistencia. Como dijimos la primera clase la persistencia no es tema de nuestra materia, sin embargo para poder hacer una aplicación completa tenemos que tener alguna noción de ella.
No nos va a interesar "cómo funciona" la persistencia, pero sí cómo interactuamos con ella desde el resto de la aplicación.

La forma que le vamos a dar nosotros a la interfaz con nuestra persistencia es utilizando objetos Home. Tal vez las hayan escuchado nombrar como DAOs, la idea es similar pero nos gusta más hablar de Homes, una home es el lugar donde "viven" todos los objetos de un mismo tipo. En otros lenguajes como Smalltalk, donde las clases son objetos de verdad, estos podrían ser métodos de clase pero acá necesitamos tener un objeto aparte.

Les estamos pasando unas homes que ya tenemos hechas, basadas en db4o. Si quieren pueden mirar cómo trabajan, pero a los efectos de esta materia no es importante. Las cosas que puedo hacer con una de estas Homes son:
  • agregar o eliminar un objeto (métodos típicos de una colección)
  • actualizar un objeto (esto ya es especial)
  • diferentes tipos de búsquedas, las nuestra tienen buscarPorId, buscarByExample y buscarTodos


Otra relación que tenemos con la persistencia es que muchas veces recae sobre ella el manejo de transacciones. Si bien creemos que esa decisión es discutible es lo que pasa en la amplia mayoría de los sistemas que uno desarrolla y salirse de ese esquema es no sólo complicado sino controversial, por lo tanto vamos a adaptarnos a ello (para los interesados podemos ver otras propuestas en otro momento).

En este caso no va a ser necesario manejar manualmente las transacciones, pero sí tenemos que ser conscientes de que la persistencia es transaccional. Concretamente, si modifico un objeto pero no llamo al actualizar de la home, esos cambios se pierden. En muchos sistemas esa característica se utiliza para implementar la cancelación de las modificaciones que uno hace.

1. Introducción al ejemplo del VideoClub


Cerrado eso pasamos a ver un nuevo ejemplo: Videoclub. Por ahora nos vamos a concentrar en la pantalla que puede crear un socio.

De la implementación de esa ventana podemos ver primero un par de detalles técnicos:
  • Extendemos de Dialog
  • Usa otro tipo de layout: ColumnLayout
  • El botón aceptar es default
  • Setea el título de la ventana

Otra cosa interesante es ver el diseño, que no es muy complejo pero me interesa remarcar: vale diseñar en la UI. En particular estamos acá usando un diseño muy simple, una superclase para poner comportamiento común y un template method para integrar lo general con lo específico.

Y luego algunas cosas un poco más conceptuales relacionadas con el binding:
  • Los labels tienen un valor fijo en lugar de un binding.
  • Un adapter para las fechas.

2. Acciones

Los dos botones invocan métodos sobre el dialog y no sobre el modelo. ¿Qué hacen la acción aceptar? Dos cosas
  • Inserta el objeto
  • Cierra la ventana
Vemos entonces que la aplicación tiene dos tipos de acciones, de vista (cerrar la ventana) y de modelo (crear el socio). En este caso esto se incrementa con un método en la vista que ejecuta ambos, otra opción sería hacer un listener (controller) para las dos cosas. (El motivo que lleva a este diseño lo vamos a ver la semana que viene.)

Es importante destacar que la vista ni el controller (listener) deben tener lógica del modelo, en todo caso lo que hacen es delegar al modelo para que él haga su trabajo. (Una variante sería tener una acción de modelo que dispara un evento y la vista lo escucha.)

3. Adapters.

En general, los datos de la UI tienen formatos distintos a los que tiene el modelo, muchas veces pasa. En los controles simples normalmente la información se ingresa como texto, que luego muchas veces debe ser convertida a números o fechas.

En el caso de Arena, algunas de esas conversiones son hechas automáticamente, lo vimos en el caso del ConversorDeMedidas (convertía Strings a números automáticamente). En este caso el conversor de fechas default no nos sirve, entonces hicimos uno propio. En Arena uno puede hacer sus propios conversores extendiendo de Adapter.

Idealmente uno intenta evitar modificar el modelo para adaptarlo a la vista, los Adapters nos permiten hacer eso.

Ya vimos tres formas de controller: Action, Adapter y binding (los objetos concretos que forman un Binding son un poco más complicados, así que por ahora lo vimos sólo por arriba).

4. Validaciones y error panel.

Al ver el Adapter de fecha vimos que tiraba una UserException en caso que no pueda convertir una fecha. También vemos que se tiran errores desde el modelo. Con eso en mente podemos ver algunos tipos de errores y la forma de manejarlos:
  • Errores de conversión: lo ideal es que esos errores no afecten al modelo, el lugar para hacer esto es lógicamente el Adapter.
  • Errores de validación de datos: por ejemplo "la fecha debe ser posterior a la actual", eso es mejor hacerlo en el modelo, es una regla de negocio.
  • Errores que se producen al ejecutar una acción (en este caso se muestran distinto porque se producen "al ejecutar" y no se validan antes pero es en parte una limitación del framework).

Nuestras ventanas tienen un status, que recolecta todos los errores asociados a la ventana, contra ese estado hay dos bindings:
  • El panel de arriba bindea su contenido con el mensaje de error.
  • La habilitación / deshabilitación de los botones
  • Y también cambia el color.

Esto es un ejemplo de las cosas que se pueden hacer con bindings.

5. Resumen

Una cosa importante que vimos varias veces en esta clase es la relación entre las responsabilidades que asignamos a vista/controller o a modelo:
  • Validaciones que ponemos en un lugar o en otro
  • Lo mismo con las acciones.

Discutir vista vs. controller es menos interesante, pero mantener limpio el modelo es una cualidad importante de un sistema.

Comments