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

Clase 4 - 7/09/2011

publicado a la‎(s)‎ 7 sept. 2011 17:27 por gisela decuzzi   [ actualizado el 7 sept. 2011 17:51 ]

Repaso

Hicimos repaso de lo que vimos hasta ahora:
    MVC
        MODELO
        VISTA
        CONTROLADOR
¿Para qué queremos esto? Para construir aplicaciones. Hasta ahora lo que vinimos viendo era el Modelo, ahora queremos mostrar ese modelo.

Analizamos el ejemplo del controlador reflejando como matcheaba la vista con el modelo, hablamos un poco de los objetos que componen la vista.
Digimos que hay al menos 4:
  •     un panel
  •     un textBox
  •     un label
  •     un boton
Quisimos decir algunas de las responsabilidades de los objetos de la vista, dijimos que:
  •     Sabe interactuar con el usuario (Sabe mostrarse en pantalla)
  •     Sabe interactuar con lo que es parte de la aplicación
Esta interacción se hace por asociación:
  •     podemos definir un evento con una acción, un ejemplo de esa acción es el MessageSender, podemos decir que al hacer click en un botón le mande un mensaje a un objeto
  •     podemos bindearlo a una propiedad (pensando propiedad como el par getter/setter)

Videoclub

Volvimos al ejemplo del Videoclub
  1. Empezamos por la ventana Editar, nos preguntamos ¿Cuál es el modelo? -> Muestra los datos de un socio, entonces su modelo es un socio
  2. Volvimos a la Ventana Principal y nos preguntamos ¿Cual es el modelo? Y aca no fue tan simple, entonces la analizamos. En función de lo que podíamos hacer:
    • Buscar un socio
    • Buscar segun un criterio
    • Ver el resultado de la búsqueda
    • Eliminar un socio
    • ...
Empeazamos a analizar
    Buscar -> ¿Es propio buscar de un socio? La verdad que no. Dijimos que el modelo deberia de ser el que guarda a los socios, solo que no sabemos quien es :(
        No nos parece una logica propia del controlador, NO queremos complejizar los controladores.
        No tenemos un Modelo que calce con lo que queremos, pero podriamos extenderlo.
Fuimos por el lado de extender el modelo, hablamos de la principal ventaja para nosotros: poder testear. Si la logica de buscar esta desacoplada de la vista y la tecnologia y los controladores hace que sea posible hacer test de unitarios.
Entonces creamos un nuevo modelo el Buscador: un objeto que tiene un estado propio y bindea casi uno a uno con la vista (como antes)

A este objeto nuevo que vamos a crear lo llamamos MODELO DE APLICACION ya que está en una zona gris, la idea de un buscador puede no ser propio del dominio en el que estamos hablando pero por lo que necesitamos hacer es una idea que tiene sentido. (MMVC)

Se diferencian de los modelos de dominio en cuanto al ciclo de vida.
Hablamos del ciclo de vida de un objeto de dominio, tomamos el ejemplo del socio:
  • se crea al hacer click en nuevo Socio (es explícita, la hace el usuario)
  • deja de existir al hacer click en remove (es explícita, la hace el usuario)
    A este ciclo de vida le decimos persistente. La vida del objeto depende del usuario, puede estar hasta que el usuario decida sacarlo.
Pensamos en el ciclo de vida de un modelo de aplicación, tomamos el ejemplo del buscador:
  • al abrir la pantalla se crea un nuevo objeto (cada panatalla tiene su propio objeto)
  • se destruye al cerrar la pantalla
    A este ciclo de vida le decimos contingente (también le podemos decir "single purpose"). La vida del objeto está acotada a la vida de la pantalla es mucho mas corta en comparación con un objeto de dominio.

Volvimos al ejemplo del buscador y mostramos BuscadorSociosWindow. Mirando el código revisamos la clase Search para ver las propiedades que tenía y un poquito de su comportamiento.

Revisamos los métodos de SearchWindow (que tenía una superclase asi que lo fuimos navegando).
Llegamos a estas conclusiones:
>>createMainTemplate
    - llama a su padre (que agrega el panel de errores)
    - crea la grilla de resultados
        - Instancia la tabla (como ya vimos)
        - Bindea el contenido de la tabla a una propiedad (contra RESULTS)
        - Bindea el objeto seleccionado de la tabla (contra SELECTED)
        - Describe la grilla
            - Crea las columnas
            - Bindea las columnas contra el titulo de la columna
            - Bindea las celdas de la columna contra:
                - Una propiedad del modelo
                - Un tranformer: codifica/decodifica entre los dos mundos (el modelo y la vista). Cuando algo se modifica en el modelo tiene que impactar en la vista y viceversa, a veces la representación visual es distinta del modelo. Por ejemplo las fechas en mi modelo es un objeto Date en mi vista es algo que tiene el formato DD/MM/AAAA. Un objeto transformer está en el medio traduciendo para los dos lados. De hecho un tranformer puede validar ciertas cosas.
    - crea la grilla de acciones
        Los botones que estan en esta pantalla son un poco mas complicados a los que veniamos viendo porque refieren al objeto que esta seleccionado en la grilla.
        Vimos como se bindeaban los eventos del boton con distintos objetos.
            - EDIT disparaba un envio de mensaje a la propia ventana, donde:
                - crea una nueva ventana
                - la abre,
                - habia una linea mas complicada en el medio donde bindeaba el evento onAccept (cuando alguien acepto la edición) al método SEARCH
                - bindea el Enable del botón (es decir cuando se activa) a un listener especial
                    Hablamos de como es que se hacen los bindings. Dijimos que en un momento veiamos:
                    ? -> validator -> transformer -> validator -> (update) -> ?
                    Y que ahora ibamos a pensarlo con un objeto mas en el medio:
                    ? -> listener/observer/observable -> validator -> transformer -> validator -> (update) -> ?

En el medio hablamos de Reflection: Es la manera de lograr que un mismo programa se observe y modifique su propia estructura y comportamiento en tiempo de ejecución. Particularmente Arena lo usa mucho para hacer cosas como mandar un mensaje a un objeto a través de un string.
Dijimos que es mas prolijo y ordenado definir constantes y usar esas constantes en vez de caer en un uso indiscriminado de strings por toda nuestra aplicacion que puede terminar con algo inmantenible y un dolor de cabeza si alguien renombra una variable.

>>createFormPanel
    crea un buscador
        Instancia de la clase SearchByExample
            Tiene atributo selected
            Tiene atributo results
            Tiene atributo example (en nuestro caso es un socio)
            Tiene el metodo search
    Setea como modelo del panel que contiene al buscador el ejemplo del search (esto lo logra mandandole el mensaje bindContents a la propiedad EXAMPLE). Con esto acotamos el modelo que va a tener nuestro panel restringiendolo solo a un socio.





Home

Vimos lo que son las homes en Arena, hablamos de una home a partir de la necesidad de persistir nuestros objetos.
Por cada elemeto que queremos que sea conocido globalmente vamos a tener un Home, y las homes son conocidas por el dominio en el sentido de verlo como un contenedor de mi objeto de dominio.
Los vamos a considerar Objetos de aplicacion:
  • MODELO DE APLICACION
  • MODELO DE DOMINIO
  • HOME
Las tres conforman mi dominio.
El ciclo de vida del HOME no es ni persistente ni contingente, aparece cuando nace el sistema y muere con mi sistema, le decimos que son permanantes.

De las Homes Arena tiene 2 implementaciones que ya les damos una que guarda los objetos en memoria y otra que usa db4o, para usar pueden usar la que quieren e incluso implementar su propia home que persiste distinto pero eso escapa de nuestra materia.








Comments