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

Bitácoras 2011 S2

Clase 8 - Wicket Parte 1

publicado a la‎(s)‎ 12 oct. 2011 16:41 por gisela decuzzi   [ actualizado el 12 oct. 2011 16:45 ]

Modelo 2 de Java

MVC:

  • Model: java

  • View: jsp

  • Controller: servlet

Y no nos parecio tan feliz como el Arena porque nuestros controlles no se bindeaban contra un modelo y la metáfora

Hablamos de que no resultaba sencillo reutilizar en esta arquitectura llegamos a la conclusión de que las abstracciones estan orientadas al protocolo que usamos y no a los componentes que manejamos.

Entonces no es sencillo implementar cosas como:

  • una grilla reordenable

  • combos encadenados


Arriba de este protocolo se paran otros fwks y modelan estos componentes, vamos a ver Apache Wicket que ya hizo mucho de esto por nosotros.

Wicket

Creación de un proyecto wicket

  1. new MVN project

  2. (elegimos el archetype) wicket-archetype-quickstart

  3. le damos un nombre al grupo y al artefacto

Lo que sigue es opcional pero altamente recomnsable

  1. Revisamos que el proyecto se haya generado bien (esten las dependencias, la estructura sea correcta)

  2. Deployamos la aplicación en el servidor y lo iniciamos para revisar que no haya ningun problemaen el ambiente



Las aplicaciones Wicket modelan un obeto Aplicación, que extiende de WebApplication, funciona como un singleton y todo lo que sea transversal a la aplicación va a estar en este objeto.

Nos obliga a implementar:

  • getHomePage

    • Devuelven una página (Wicket también modela el objeto Page que representa a nuestra página)



WebPage:

Nuestras páginas van a extender de WebPage y va a ser ahi donde lo configuremos y agreguemos nuestros componentes (componente, componente, componente) para los que no se acurden repasen el patron composite.

Cada página tiene asociado un markup (un archivo html que por default se llama igual al nombre del componente). En estos markups NO podemos poner código Java.

Wicket tiene sus propios bindeos que vincula el html con el componente Java. Para mostrarlo Wicket va a instanciar nuestro objeto página y a reemplazar el valor del componente por el dinámico.


En un ejemplo:

(En el constructor de una página)

String laVersion= “BLAH”;

add(new Label(“version”, laVersion));


(En la vista de esa página)

<span wicket:id=”version”>valor por default</span>


Datos importantes:

  • La idea de Wicket es que todos tus componentes están presentes en la vista. Es decir que la renderización de componentes es uno a uno cada compenente que está en el html está en la clase java. Por lo que:

    • si agregan un componente en la clase si no lo muestran en el html (y estan ejecutando en modo developer) les va a tirar un error.

    • si en el html agregan componentes que no estan en la clase java va a tirar un error

    • si referencian mas de una vez el mismo id de componente va a tirar un error


En wicket la vista es tanto el html como la clase java.


Vimos algunas cosas de Wicket y la afinidad a las inner classes. Y de alguna manera hablamos sobre la decisión de que los componentes por default de Wicket son abstractos y prefieren la estrategia de herencia por sobre composición por lo que por lo general cuando instanciamos algunos componentes como por ejemplo un Link nos obliga a dar una implementación concreta o definir el comportamiento al hacer el click y esto se logra redefiniendo el método onClick.


Vimos que los bindings no son tan directos y que por default Wicket asume que el componente no va a cambiar pero nos permite crear nuestros propios modelos.

Por ejemplo:

new Label(“contador”,miVariable)

el contador tiene un contenido estático que vale lo que vale la variable al momento de instanciación.

Es diferente a definirle explicitamente un modelo:

new Label(“contador”, new PropertyModel(this, “contador”));

PropertyModel es una clase concreta que nos da Wicket (que se parece mas a un controller por mas que se llame Model) que asocia un objeto con una propiedad. De esta forma ahora nuestro label quedo bindeado.

Más sobre modelos de Wicket pueden seguir leyendo acá

Wicket es un framework stateful en contraposición a algunas cosas que hablabamos la clase pasada que era stateless (REST).













Clase 6 - Web - servlets - jsp

publicado a la‎(s)‎ 28 sept. 2011 17:18 por gisela decuzzi   [ actualizado el 28 sept. 2011 17:21 ]

Arrancamos diciendo que teniamos problemas mas complejos y que ya no nos servia el compartir html estático porque queremos hacer aplicaciones con datos dinámicos.


Tomcat

Es un application Server. Donde viven nuestros objetos y es el application server el que se encarga de algunas cuestiones tecnológicas.

Nosotros vamos a usar Tomcat tambien hay otros como por ejemplo:

  1. Glassfish

  2. Jboss

  3. Caucho

  4. ...


Servlet: es una interfaz, que principalmente tiene un método service(Request, Response).

Request: dada la informacion que viene me provee de una interfaz para manipular los datos del pedido

Response: es nuestra manera de dar respuesta al pedido.

Las tres son interfaces de bajo nivel, con esto queremos decir que están muy pegadas al modelo web: request, response y nos abstrae muy poco de lo que representa.


Server Page: Recibe pedido http devuelve una pagina html abstrayendonos a mayor nivel. Nos permite incluir contenido dinámico. Ya no tenemos una página html puramente estática.

Comunmente en páginas jsp se usa mucho scriptlets que es algo que no vamos a ver en UI porque involucra muchas cuestiones tecnológicas que nos desvían de nuestro objetivo.


Expresion Lenguage: Lenguaje de expresiones, expresiones que se calculan dinámicamente como por ejemplo ${nombre}


Taglibrary: Son tags propios de las distintas tecnologías, uno puede crear sus propias librerias de tags, en UI no vamos a implementar nuestras propias librerias de tags pero sí vamos a usar jstl que es una librería que ya viene implementada. Vimos ejemplos mostrando estructuras de control ya implementadas, en el ejemplo:

<c:if test=”${sessionScope.libros != null}”>

</c:if>

<c:forEach itmes=...>

</c:forEach>


Empezamos a ver MVC en la web con las tecnologías que mencionamos:

M: programado en nuestro dominio

V: html, jsp

C: servlets


Pasamos a algo más práctico y fuimos al ejemplo de un buscador de libros donde teniamos:

    • Un campo para introducir texto y buscar los libros que tengan como titulo lo buscado (o parte de lo buscado)

    • Una tabla donde veiamos las respuetas

    • A su vez los nombres de los libros eran links que nos llevaba a otra página.


Antes de ver el código nos imaginamos los objetos que teniamos dijimos:


Fuimos al codigo y navegamos el proyecto.

Buscamos las páginas (los .jsp) encontramos detalle.jsp e index.jsp (ahí resulto lo que imaginabamos :)).

Abrimos index.jsp

Vimos varios encabezados, que los mencionamos rápidamente para poder ver el contenido dinámico

Dijimos que su funcionamiento era:

Todos los pedidos llegan a un servlet, el servlet delega en el dominio,

Vimos que habia un form que hacia un submit haciendo un post llendo a la direccion search y nos preguntamos ¿como los resuelve? Entonces nos fijamos en el web.xml ahí vimos que estaba definiendo que todos los pedidos que vengan con el patron /search los va a enviar a un SearchServlet (que estaba especificado donde se creaba).

Entonces nos fuimos a SearchServlet y vimos el método doPost, hablamos de servlets y jsp y por qué decimos tantas veces que no nos parece una tecnología “felíz”.

Volvimos al método doPost:

    • obteníamos el título del request

    • buscabamos el libro (se lo delegabamos al dominio: la Biblioteca)

    • seteabamos en la session un atributo libros (que era el resultado de la busqueda)

    • al request lo reenviabamos al index.jsp

Hablamos 4 formas de pasar informacion en jsp (en otras tecnologias el mismo concepto esta con distintos nombres):

  1. Parámetros: Son los que vienen por ejemplo en la url al hacer un get

  2. Requests: El objeto que llega a mi servlet: me llegó por parámetro y como todo objeto lo puedo mandar también y lo usamos para compartir información entre todos los objetos a los que les llegó.

  3. Session: Espacio compartido entre todos los pedidos de un mismo usuario.

  4. Application: Información común a todos los usuarios. (no es generalmente usado)

  5. Page scope: le corresponde solamente a la página que setteo ese objeto


Hablamos sobre el estado dentro de la web y el efecto de nuestras acciones.

Y a partir de ahí mencionamos algunos problemas de la web

Estado

Contamos que el http es un protocolo no orientado a la conexión y que en realidad un servlet es un modelo donde llega un pedido lo procesa, responde y se olvidó de todo lo que pasó, del usuario, etc.

Pero nosotros queremos acordarnos de algunas cosas, como por ejemplo el usuario. Nosotros queremos mantener estado.

A nivel usuario eso se logra con la sesion.

El primer pedido manda un identificador para que genere una cookie y el browser se compromete a que en cada pedido le mande ese identificador y asi establece una sesión (que esta en el server). El browser decide en qué momento uno esta en la misma sesión o no.

Consecuencias del abuso de la sesion

    • problemas de memoria, si nadie saca lo que puso en la sesion la vamos arrastrando

    • colisiones de nombres en el modelo clave-valor en la sesión

Doble submit

¿Cómo distinguir un pedido verdadero de uno accidental? ¿O un pedido que llega por un refresh?

Comunicación unidireccional

La comunicación se inicia del lado del cliente hacia el servidor. Todo lo que emule una conexión bidireccional en realidad son “trucos” que se hace para hacernos creer que esto está pasando. Porque la tecnología web no contempla este modelo, con lo cual a partir de ahí se nos hace todo cuesta para arriba.

Revisamos nuestra página tan simple y la vimos con mas cariño entonces apreciamos otras cosas que estaban pasando:

  1. Cuando haces una busqueda el textfield tiene el valor buscado ¿cómo lo obtuvo? En realidad SIEMPRE lo estamos obteniendo como un parámetro vimos el jsp y notamos que el atributo titulo del input estaba seteado a “${param.titulo}”. Si se lo sacamos nuestro input ya no muestra lo buscado

  2. No siempre mostraba la grilla con los resultados ¿Como lo maneja? Para eso vimos que usaba el tag <c:if ...> que chequeaba por la presencia del atributo libros dentro de la sesion y que es en nuestro server donde se setea esta variable.

  3. El contenido de la grilla es distinta según los resultados de la búsqueda. Miramos como lo logra con el <c:forEach ...> y mas expresiones que se usan para reemplazar distintas variables

Nos fuimos a detalle.jsp

Vimos otro tag set que setea una variable con scope page (libro) y al mirar el resto de la página dijimos que era muy similar a lo que vimos en index con lo que no nos detuvimos mucho en los tags que usamos.


Clase 5 - 14/9/2011 - Introducción a la Programación Web

publicado a la‎(s)‎ 15 sept. 2011 9:25 por Nicolas Passerini   [ actualizado el 16 sept. 2011 12:29 por gisela decuzzi ]

La primera parte de la clase estuvo dedicada principalmente a  la corrección de trabajos prácticos. Sus notas de seguimiento están publicadas aquí.

Durante esa parte también explicamos el concepto de Layout y los layouts básicos que permite el Arena. En el svn pueden encontrar un proyecto con varios ejemplos de layout, más allá de los que vimos en clase.

A las 8 arrancamos la parte práctica, introduciendo algunos conceptos básicos de programación web. Hay varias cosas para leer al respecto en la página del Módulo A de la Unidad 3
El ejemplo que vimos lo van a encontrar en la página de Ejemplos básicos de programación web (se llama "primerEjemplo-ui-html"). 

Nota Importante: Este primer ejemplo no requiere de tener un servidor para poder verlo funcionando (en este momento es importante porque no vimos cómo levantar el servidor ni nada que se le parezca, eso lo vamos a ver la clase que viene).


Les dejo algunas tareas para hacer para la próxima clase (en 15 días):
  • En primer lugar terminar el TP (obvio).
  • Leer los apuntes asociados al módulo A (en "temario detallado"). Sólo los tres primeros (arquitectura web, html y css). Esto es muy rápido porque son muy cortitos, es un repaso de lo que vimos en clase. Tenemos un tema nuevo y tenemos tiempo, aprovechemos para evacuar cualquier duda que surja, usemos la lista si algo no se entiende.
  • Jugar un poco con HTML y CSS. Pueden arrancar instalándose el ejemplo que vimos en clase y hacerle modificaciones. Lo ideal sería armar la página que va a mostrar el tablero en el TP2.
    Por ahora no vimos cómo generar contenido dinámico, así que sería una vista estática del tablero. 
    Para eso pueden mirar los tutoriales de HTML y CSS que están también en la página del Módulo A. Esos no conviene leerlos completos de corrido, son muy largos y técnicos. Sirven como referencia.

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.








Clase 2 - Miércoles 24/08/2011 - Unidad2: MVC, Bindings & Arena

publicado a la‎(s)‎ 25 ago. 2011 12:26 por Javier Fernandes   [ actualizado el 25 ago. 2011 13:57 por gisela decuzzi ]

Repaso de Maven (clase anterior)

Inicialmente repasamos algo de lo que vimos la clase pasada acerca de Maven.

Aclaramos que Maven no es solo un servidor. Es una herramienta que modela el concepto de proyecto, dependencia, ciclo de vida, etc.
A diferencia de una herramienta como subversion que solo se encarga de versionar archivos, pero "archivos en general". Subversion no conoce el concepto de "proyecto", para el todos son "archivos" y ya

Se parecen en una cosa, en que Maven también tiene servidores, donde se publican los proyectos. Pero lo que se publican no son archivos sino artefactos, con su pom y sus versiones distribuibles. Por ejemplo el jar. De hecho podemos tener más cosas como el un zip con el código fuente, los javadocs, los tests, etc. Depende como configuremos Maven y qué cosas querramos publicar.

Pueden mirar su repositorio local para ver cómo es, cómo se estructura y qué contenido tienen:

$UI_HOME/data/maven/repo/

Ejemplo de archivos que puede tener un artefacto:

commons-beanutils-1.8.3-javadoc.jar

commons-beanutils-1.8.3-javadoc.jar.asc

commons-beanutils-1.8.3-javadoc.jar.md5

commons-beanutils-1.8.3-javadoc.jar.sha1

commons-beanutils-1.8.3-sources.jar

commons-beanutils-1.8.3-sources.jar.asc

commons-beanutils-1.8.3-sources.jar.md5

commons-beanutils-1.8.3-sources.jar.sha1

commons-beanutils-1.8.3.jar

commons-beanutils-1.8.3.jar.asc

commons-beanutils-1.8.3.jar.md5

commons-beanutils-1.8.3.jar.sha1

commons-beanutils-1.8.3.pom

commons-beanutils-1.8.3.pom.asc

commons-beanutils-1.8.3.pom.md5

commons-beanutils-1.8.3.pom.sha1

Los archivos. asc y .md5 contienen un checksum que permite al cliente de maven verificar que al bajarse uno de estos archivos no se haya introducido ningún error en la comunicación. Es decir que no se hayan perdido algunos bytes por ahí en el camino
Pero podemos ver:
  • jar con el javadoc (recuerden que jar = zip)
  • jar con el código fuente (sources)
  • jar del proyecto (binarios)
  • pom
Para más información, lean el apunte de maven.

Un poquito de SVN

Recordamos que el SVN es una herramienta de versionado de código. Que va manejando versiones del repositorio. Y que ante cada commit se incrementa.
Además sabe mostrarnos la historia de cambios para un archivo/carpeta dados.

Mostramos  un poquito el plugin de svn de eclipse, que nos facilita bastante las cosas, ya que el cliente de consola es bastante precario.

Si van a un archivo java, boton derecho -> Team -> Show History
Van a ver una lista de cambios publicados en el svn para ese archivo, la fecha, autor, comentario, etc.



Unidad 2


Arrancamos entonces con la Unidad 2 con una introducción de la mano de Gise.

Tiramos algunas ideas que nos vienen a la cabeza cuando hablamos de Interfaz de Usuario (UI del inglés a partir de ahora).

Diferentes tipos de controles:
  • textbox: para editar/ingresar un valor
  • label: para mostrar un texto
  • Compuestos como grillas, etc.

Layouts

Contamos la idea de que los elementos tienen que ser organizados y posicionados en la interfaz. Este proceso se llama layout. Más adelante en las siguientes clases vamos a ver las diferentes estratégias de layout con ejemplos.

Bindings

Un binding significa un "vínculo" entre un elemento de la UI y nuestro modelo (objeto de negocio desacoplado de la UI).
El concepto de vínculo es bastante poderoso. Y vamos a ver que de acuerdo a la implementación, es decir, al framework de UI que estemos usando, ese vínculo va a tener más o menos responsabilidades.

La idea del binding, y de tener un modelo detrás, es lo que nos permite darle sentido a la interfaz de usuario. Si no, solo sería una agrupación de controles.

Recordando algunos patrones

Nombramos el pattern Composite para describir un tipo de elemento de UI, que contiene otros elementos dentro. Y que de esta forma pueden ser tratados polimórficamente.
Por ejemplo, una "grilla" o tabla, que tiene elementos como filas, columnas, celdas.

También vimos que el patrón Observer/Listener se utiliza a nivel de UI, ya que es una buena forma de interacción entre el modelo y los componentes de UI.
De esta forma nuestro modelo queda desacoplado de las clases de la vista. Aunque interactúan a través de este patrón.

MVC

Luego de recordar estos patrones nos metimos a contar un poco lo que es el patron MVC.
Model, View, Controller.

La vista en nuestro ejemplo eran los controles o elementos visibles como el textbox, el botón, etc.

El usuario utiliza los controles de la vista para interactuar con la aplicación. La vista se encarga de propagar eventos como un onClick(), onBlur(), etc.
Y luego la acción a realizar ante este evento, se implementa mediante un Controlador.

Como el controlador sigue siendo un objeto acoplado a la Vista, si escribieramos nuestra lógica de negocio en los controllers, quedaría dispersa entre muchos controllers, rompiendo la idea de objetos. No tendríamos modelado nuestro negocio en objetos.

Entonces, nuestros controllers van a ser bien chiquitos, y genéricos, para poder reutilizarlos, y no tener que codificarlos para cada pantalla, para cada aplicación.

Estos controllers van a trabajar con un Modelo. Entonces, el controller vincula un control de la Vista con el Modelo. Por ejemplo, para editar una propiedad del objeto de negocio en un textbox, o para invocar un método del objeto ante un click de un botón.


Segunda Parte: MVC y bindings en Arena

Después de la intro teórica y de explicar los conceptos nos metemos a ver un ejemplo práctico y su implementación en Arena (y luego SWT).

Hablamos de arquitecturas cliente pesado (mas asociado a aplicaciones de escritorios) y cliente liviano (mas asociado a aplicaciones web).
Mencionamos que el origen de la web fue para compartir texto.

Hicimos un poco de historia y mencionamos las primeras tecnologias java
  • AWT -> Swing (que se para sobre AWT) donde ambos frameworks dibujaban por su cuenta sus propios controles. Y un poco por esto y por todas las criticas de que es demasiado lento se fue dejando de lado.
  • SWT: un framework desarrollado por el proyecto Eclipse para realizar interfaces gráficas en aplicaciones de escritorio que no usa ni awt (ni swing) y usa los componentes del sistema operativo. Donde no existe el concepto de binding a un modelo.
  • Sobre SWT se construyo Jface que le da algunas nociones de modelo y binding, de todos modos tienen cosas que uno consideraria no muy feliz.
  • Por lo cual a fines didacticos surge Arena (que se para sobre JFace y nos va a permitir hacer aplicaciones de escritorio).

Ejemplo: Conversor de Millas a Kilómetros.

Pensamos un ejemplo sencillo, convertir de millas a kilometros y pensamos en que objetos (primero de la interfaz) queriamos tener, o cómo se vería la aplicación:
Hablamos que necesitabamos:
  • textbox: el lugar donde podemos ingresar las millas.
  • label: para mostrar el resultado de la conversion.
  • button: para Convertir, la forma de decirle que realice la acción.
  • frame: el contenedor de los demas componentes.
Hablamos de la logica que necesitariamos que en nuestro caso seria la de el calculo de conversion y mencionamos algunas limitaciones si no tuviesemos el modelo desacoplado de la vista: los tests unitarios que no se podrian hacer :(

El modelo (version "0")


Nos detuvimos a pensar en el modelo de objetos y lo pensamos desde un testcase (TDD), surgio una clase "Conversor" que sabe convertir por lo que nos gustaria que entienda el mensaje convertir que espera las millas y devuelvo los kilometros.
Fuimos por ese lado:

    #Conversor >> convertir: millas
        ^ millas * 1.60934.


O en su versión Java:

public class Conversor {

    public double convertir(double millas) {
        return millas * 1.60934
    }

}

Y tuvimos algunos problemas... Quisimos hacer una correspondencia uno a uno entre nuestro modelo y nuestra vista y vimos que no lo podiamos hacer modelandolo asi. O que en realidad complicaba un poco las cosas, y aparecía un "code smell" que nos indicaba que nos faltaba una abstracción.

Veamos esta conexión
  • Frame --> Modelo: Converter
  • textbox de millas --> Modelo: nada
  • label --> Modelo: nada
  • Botón --> con un listener de "onclick" que invoca el método "convertir"

Problemas:

  • Nuestro textbox millas no estaba conectado con el modelo.
  • Lo cual hacia que al clickear convertir tuvieramos que hacer demasiadas cosas:
    • obtener las millas del objeto textbox.
    • convertir el string (que tenia el textbox) a numero (double).
    • mandar el mensaje convertir con las millas (como parámetro de tipo double).
    • el resultado convertirlo de vuelta a String y  setearlo en el label donde se muestra la conversión
Como consecuencia, nuestro controller, en este caso el listener del onClick del botón quedaba bastante complejo y hacía demasiadas cosas.

Entonces dijimos que nos gustaria tener una implementación del patrón mvc un poco más feliz, que respete las buenas prácticas de objetos. Para eso pensamos en otra solución...

Refactor: Versión "1"

Decidimos:
  • vincular las millas del textbox a una propiedad del Converter (Converter.millas).
  • vincular los kilometros del label a otra propiedad (Converter.kilometros).
  • al apretar convertir mandarle el mensaje convertir al conversor (que no devuelve nada y no recibe parametros).
La relación ahora queda:

  • textbox(millas) <---> Converter.millas
  • label(km) <--- Converter.kilometros
  • Boton <---> Converter.convertir()
Y nuestro modelo (simplificado acá) quedaría asi:

public class Conversor {

      public void convertir() {... }

     public void setMillas(double millas) {... }

     public double getKilometros() {... }

}

Bindings

Para vincular un componente de ui con un atributo de nuestro objeto usamos otro controller (binding) que actualiza el modelo.

Hablamos un poco del binding y dijimos que es como un Mediator y un Listener que esta escuchando el evento de modificacion de su componente de ui asociado (y puede ser bidireccional, hablamos del label kilometros que es un ejemplo de una interaccion de "modelo a vista").

Particularmente los bindings de Arena tienen un plus que es es saber hacer ciertas adaptaciones (por ejemplo si a un tetbox lo asociamos con una propiedad que es un double lo transforma automaticamente).

Mostramos la implementacion del Converter con arena y en el medio

Java "Beans"

Hablamos de lo que es un bean, y lo que seria el contrato de un Java Bean (NO confundir con EJB), que nos dice que tenemos que tener:
  • accesors para nuestras propiedades (getters y setters). OJO que una propiedad no necesariamente es una variable del objeto. Simplemente respeta el hecho de que entiende los mensajes getSaraza y setSaraza. Algo importante que esta bueno notar es que si tiene el getter y NO el setter esa propiedad es inmutable.
  • un constructor vacío.
Noten que respetar el contrato de Java Bean nunca implica que tengamos objetos que solo contienen datos (y getters y setters). Nuestros objetos pueden (y deberían) seguir teniendo comportamiento.


Analizamos la solucion que pudimos hacer en arena y como afecto un cambio (sacar el boton convertir y que se convierta solo al escribir en el textbox) y mostramos otra solucion de un ejemplo similar sin la separacion de Modelo-Vista-Controlador.


Arquitectura de Layers (Capas lógicas) / Tiers (Capas físicas)

En algún momento de la clase también hablamos un poco de arquitecturas e hicimos una diferencia entre Layer y tier (multi-tier architecture)
  • Layer: capa lógica ==> Estructurar la aplicacion en capas pero NO implica separacion física. Hablamos un poco de ejemplos con las capas que mas se usan, por ejemplo una aplicacion que tiene una capa de persistencia y la capa del modelo no conoce nada de esta capa
  • Tier: capa física ==> Estructurar la aplicacion e implica separacion física (las capas en distintas máquina resolviendo la comunicación entre equipos físicos)



Material Extra

  • SWT: http://www.eclipse.org/swt/
  • Tutorial de Swing: http://www.javabeginner.com/java-swing/java-swing-tutorial

Tareas para la próxima clase

  • Haber leído esta bitácora (bien si llegaron acá luego de leer todo, mal si solo scrollearon rápido sin leer, vuelvan para arriba!)
  • Importar los proyectos de arena y el conversor (mandamos por mail) y jugar un poco con eso.
  • Leer esta página que es un script de la misma clase pero desde el punto de vista de otro docente amigo que se dá en la Universidad de San Martín. Como nuestra clase no fue exáctamente igual, y por momentos nos detuvimos hablar de otras cosas, esta lectura les va a ayudar a complementar con más definiciones y ejemplos.

Miércoles 17/08/2011 - Primer Clase: Unidad 1 + Entorno de Trabajo + Maven

publicado a la‎(s)‎ 22 ago. 2011 15:16 por Javier Fernandes   [ actualizado el 22 ago. 2011 15:24 por gisela decuzzi ]

Primera parte:

Aspectos administrativos de la materia

Arrancamos contando el resumen de las unidades, que se puede ver en Temario detallado. Hablamos también de la relación entre las unidades y de los objetivos de la materia que nos llevan a esa elección de temas.


Hablamos del trabajo práctico que le vamos a estar dando el enunciado de los primeros TPs la semana que viene. Contamos que va a ser una continuación (un ejemplo que crece).


Todos los trabajos prácticos son individuales. También dijimos que no tomamos un examen parcial, la aprobación de la materia se da únicamente en función de los trabajos prácticos.


También navegamos un poco el site, que tiene 4 partes principales:

  • La Materia, con todas las cuestiones adminstrativas, el programa, nuestros correos, etc.
  • Temario detallado y sus subpáginas tiene todo el material teórico, esto es material de consulta permanente que hay que ir leyendo clase por clase.
  • De Material cuelgan un montón de recursos útiles principalmente para la parte práctica de la materia ejemplos, el software para instalar junto con los instructivos necesarios para hacerlo, etc.
  • Y finalmente en la sección Mi Cursada van a encontrar:


Otra cosa que se mencionó fue la cuestión de los horarios, algunas notas al respecto:

  • La idea es hacer la primera parte teórica y la segunda parte práctica. Principalmente las primeras clases hasta que tengamos mas herramientas para trabajar van a respetar este formato.
  • La idea es que la práctica se hace mayoritariamente en el aula. La recomendación es que traten de venir seguido (o mejor: siempre). Si bien es posible hacer la práctica en casa, es mucho más difícil porque si te trabás puede que tome un rato conseguir ayuda.
  • Vamos a ser muy estrictos con las fechas de entrega, la experiencia dice que cuando nos relajamos se nos empiezan a acumular las entregas al final del cuatrimestre y terminamos perdiendo la materia por eso.


Entorno de Trabajo

Después de hacer un cambio de aula instalamos el ambiente con el dvd que armamos, de forma que en las pcs quede configurado el entorno de trabajo (eclipse, maven, svn)

Eso nos tomó bastante tiempo asi que arrancamos a eso de las 8 a hablar un poco de Maven y a hacer historia.


Maven

Contamos algunas de las cosas de las que nos abstraen los entrornos.

Hablamos de compilación, código compilado y un poco del mecanismo que usa Java. javac, .java, .class

  • Hablamos de lo que es un classpath y que en la jvm no existe el concepto ni de proyecto ni de empaquetamiento. Mostramos la solucion que nos da Eclipse y las ventajas de usar maven.

Mencionamos de forma acotada el ciclo de vida que nos da maven y como es el esquema de que un goal incluye al otro y que cada uno hace lo que tiene que hacer, dijimos que exista la posibiliad de extenderlo con un esquema basado en plugins.

Para más información acerca de Maven, pueden leer esta página del site


Aclaramos que el objetivo principal de esta materia es diseñar interfaces de usuario y (no se dijo exactamente así pero lo aclarams ahora:) eso incluye tanto el diseño interno como la forma en la que interactúa con el dominio (entendiendo además la diferencia entre diseño de sistemas y diseño gráfico).


Tarea para el hogar

  1. Ir leyendo:
    • Los puntos 1 y 2 cubren la introducción que dimos a la materia.
    • 3 y 4 es material complementario.
    • De la parte que está bajo "Material de Lectura" es muy importante ir leyendo el primero. Como dije, es largo y no espero que lo lean de un día para el otro, pero vayan avanzando con eso como para terminarlo al final del cuatrimestre (no se duerman!).
  2. Repasar las cosas que vimos en Objetos I / II. En esta materia vamos a utilizar fuertemente algunos patrones de diseño. Por las dudas deberían repasar: Observer/Listener, Composite, Strategy, Command, Template Method y Singleton. Si alguno no lo vieron o no encuentran de dónde repasarlo avisen así tiramos algo de material al respecto. La fuente básica de todo esto es el libro Design Patterns de Gama et. al., ese libro está en biblioteca (aunque también es tan famoso que se pueden buscar los capítulos en Internet).
  3. Además las primeras tecnologías que vamos a ver van a ser en la plataforma Java, así que los que no cursaron Objetos II o no se sienten duchos con el Java deberían apuntar a ponerse las pilas. Para eso, recomiendo este apunte que escribió Leo Gassman: Java para programadores objetosos, que pueden encontrar en este sitio también.

1-6 of 6