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

Bitácora 2s 2013

Clase 9

publicado a la‎(s)‎ 16 oct. 2013 15:25 por gisela decuzzi   [ actualizado el 16 oct. 2013 15:29 ]

Mencionamos RAD: Rapid Application Development
Wicket:
Framework basado en componentes
Hecho en Java
Proyecto on-going
Wicket NO pertenece a la idea de frameworks RADs

Creacion de un proyecto Wicket para java, usamos el archetype: org.apache.wicket wicket-archetype-quickstart
Estructura de la una aplicacion wicket:
  •  Application que hereda de WebApplication, responsabilidad principal:
    • redefinir getHomePage
  • Pagina que hereda de Page
    • se instancian y crean componentes y agregandose al contenedor. Todo componente tiene un ID
  • .html con codigo "pseudo" html
    • MUY acoplado con la clase java
    • referencia los componentes por ID 
    • pseudo porque en realidad no es el html que viaja al cliente, tiene tags y atributos especiales que usa el framework
  • Ideas de Wicket y la vista
    • html limpio
    • permite que el html + css sea manejado por el diseñador u otra persona
    • el contenido estatico lo reemplaza en runtime, pero se pone contenido para que sea visible
    • en el html SOLO se define layouts y se agregan componentes (con el estilo que se necesite)
    • en el .java se instancian los componentes y se define el comportamiento en caso de ser necesario
    • El html y el java asociado a ese html son ambos parte de la vista
  • Error que les va a pasar seguido:
    • Crean un componente en la parte java (el Page), pero NO lo pusieron en el HTML
  • Vimos como muestra la informacion wicket y maneras de vincular los datos
    • Hablamos de la diferencia entre setear un valor y tener un modelo atras de un contador
    • Vimos la interfaz IModel y su relacion con los binding de Arena 
  • Hablamos un poquito de la navegación en Wicket
    • vimos que a la pagina le podiamos decir: setResponsePage(..) y hablamos de la difrencia entre pasarle como parametro la clase de la pagina (instancia una nueva pagina) y la instancia de una pagina
    • notamos que por default si no indicamos a donde redireccionar se "autoredirecciona" a la misma instancia de la pagina
  • Mostramos un ejemplo cambiando un link común en uno ajax
    • Ojo con algunas cosas:
      • siempre hay que agregar al target lo que vamos a querer actualizar
      • si un componente lo vamos a querer actualizar hay que mandarle el mensaje setOutputMarkupId con true como parámetro

Clase 6

publicado a la‎(s)‎ 25 sept. 2013 19:57 por gisela decuzzi   [ actualizado el 25 sept. 2013 19:57 ]

Corregimos tps

Empezamos con web
- Hicimos un poco de historia (breve)
- Hablamos rapidamente de protocolos y un poco sobre redes
- Orientado a la conexion
- No orientado a la conexion
- http
- ftp
- Mencionamos la idea de Servidor de aplicaciones, dijimos que para la parte web ibamos a usar Tomcat
- Hablamos de la arquitectura web, algunos puntos importantes:
- Modelo Cliente Servidor
- Comunicación no orientada a la conexion (el servidor se olvida de todo)
- Esquema Pedido --> Respuesta, el cliente pide el servidor responde
- Diferencia de tecnologias y abstracciones:
- El cliente es el Browser (el Navegador que mas nos guste, Firefox, Chrome ...)
- El servidor es donde esta la aplicación corriendo
- El canal es el que comunica al cliente con el servidor (el caso tipico es internet)
- El browser entiende texto (html)
- En el servidor viven nuestros objetos y entiende pedidos (Requests) y sabe responder (Response)
- Por el canal pasan bits
- Nos detuvimos con algunas cosas:
- http
- url (partes de la url), ejemplo: http://localhost:8080/miAplicacion  donde entenmos que sigue el patron: <protocolo>://<destino>:<puerto>/<contexto>
- Hablamos de aplicaciones Java webs
- Importante el tipo de la aplicacion: El pom tiene que decir <Packaging>WAR</packaging>
- Los proyectos web tienen una estructura especifica
- Todo lo que está en webapp es lo que se expone (salvo WEB-INF, vamos a verlo la semana que viene, lo que hay y como se interpreta)
- CSS

Clase 4

publicado a la‎(s)‎ 11 sept. 2013 14:40 por gisela decuzzi   [ actualizado el 11 sept. 2013 14:40 ]

Resumen

- Arrancamos haciendo un repaso
- MVC y su relación con los ejemplos que vimos (Conversor, Apuestas).
- pensamos un ejemplo nuevo y tratamos de inferir el modelo

- Estuvimos mirando el ejemplo de celulares
- Pensamos en los modelos de las ventanas sin ver el dominio, para crear / editar no tuvimos problemas, para la pantalla inicial (de busqueda) no encontramos un modelo tan directo
- Hablamos sobre la busqueda de celulares
- Hablamos un poco sobre persistencia y mencionamos el concepto de Home 
- Pensamos en las responsabilidades de nuestra home:
- crear un celular (create)
- modificar un celular creado (update)
- eliminar un celular (delete)
- buscar un celular (find)
- Volvimos a ver el tema de ¿quien es el modelo de mi ventana de busqueda? Mencionamos varias cosas:
- La ventana no coincide con lo que imaginamos que es un celular, que es nuestra abstraccion pero es parte, vemos que hay una lista de celulares
- La home no coincide tampoco, pero hace varias cosas que serian de la home
- Pensamos en que la pantalla hace/muestra un poco de mas de un objeto
- Llegamos a la conclusion de que necesitamos un objeto que represente todo lo que nosotros necesitamos, un nuevo modelo
- Vimos todas las ideas aplicadas en el codigo del ejemplo, tambien hablamos un poco de la estructura del Arena y repasamos Dialog, Application (...).
- Dijimos que el objeto que surgio como necesidar de unir varia¿os objetos de dominio para servir de modelo de nuestra ventana es nuestro Modelo de Aplicacion, que sigue siendo agnostico de la tecnologia, pero surge puramente porque necesitamos hacer todo unido

- Hablamos sobre la navegacion entre ventanas
- Vimos un ejemplo detallado para crear la tabla
- creamos la tabla
- bindeamos los items de la tabla
- bindeamos el seleccionado (en el ejemplo lo necesitamos)
- describimos las columnas
- Titulo
- Tamaño
- Binding del contenido: OJO que este binding funciona como muchos binding, particularmente uno por cada celda que voy a tener en esa columna

- Terminamos la parte teorica temprano para que puedan ponerse al día con el tp.


Clase 3

publicado a la‎(s)‎ 4 sept. 2013 14:11 por gisela decuzzi   [ actualizado el 4 sept. 2013 14:31 ]


Clase
  • Hablamos muy poquito sobre la jerarquía de colecciones
  • La clase la dimos mostrando el ejemplo: Ruleta para ver validaciones (en el repositorio: examples/ui/arena/xtend/apuestas-ui-arena-xtend)
  • Hablamos de como crear una aplicación en Arena
    • Ventanas y jerarquía
    • Aplicación
      • Repasamos el template que nos dan las distintas ventanas
  • Hablamos sobre validaciones
    • Donde poner la validación
      • Siempre vamos a tratar de que esten definidas en el modelo
    • Separar la regla de negocio de la ejecución
  • En el ejemplo vimos validaciones y hablamos sobre la regla y la ejecución:
    • Validaciones de formatos (no letras en números)
      • Las hace automáticas Arena (en su mayoría)
      • Vimos el ejemplo del transformer para una conversión que no se hacia automatica (para un bigdecimal)
      • Vimos el ejemplo de un filtro
    • El monto de una apuesta no puede ser negativo
      • Esta en el setter de monto
      • Tira una excepción: UserException
    • El monto debe ser mayor al valor mínimo del tipo de apuesta
      • Esta en el jugar
      • Tira una UserException
      • Jugamos a cambiar el momento donde la llamamos para que este en el setter del valor
    • Cuando hay un error deshabilitar el boton de jugar
      • Se hace "automatico"
        • En realidad bindeamos el enable para cuando la propiedad valor apostado no es null
        • Tambien dijimos que se desahibite en caso de error
      • Mostramos como cambiar el codigo para que se usa una property
  • Corregimos tps
 

Algunas cosas que dijimos durante la clase
Para seguir leyendo


Clase 2

publicado a la‎(s)‎ 28 ago. 2013 13:31 por gisela decuzzi   [ actualizado el 29 ago. 2013 6:02 ]

Primer entrega del tp:
04/09 La semana que viene!!! No se duerman!
La entrega incluye:
  • Dominio
  • Tests
  • Tag en el proyecto del dominio
  • Otro proyecto para la vista creado con las dependencias a Arena  
Software:
  • Revisamos el entorno:
    • Plugins:
      • SVN
      • Maven
    • Desde el MarketPlace: Maven integration for eclipse WTP (Juno)
      • Si no vemos la opcion de market place entonces es porque tenemos otro eclipse y no el JEE que necesitamos
  • Pueden bajar los ejemplos que vemos en clase de: https://xp-dev.com/svn/uqbar
Clase:
  • Empezamos con nuestro ejemplo estrella del Conversor.
  • Mencionamos los elementos que veiamos en la ventana: textbox, boton, titulo, label, un panel que contiene todo, la ventana 
  • Hablamos de como se relacionan y lo relacionamos con los patrones que ya conocemos. Mencionamos que el panel es un composite, que los botones usan listeners, que las propiedades son observadas ...
  • Repasamos lo que significa el Modelo y lo relacionamos con el ejemplo del conversor.
  • Vimos varios ejemplos de implementaciones: SWT, Arena
  • Notamos algunas cosas en los ejemplos y discutimos sobre: 
    • mezcla de lógica
    • comunicación entre componentes
    • algunas validaciones
    • organización del código
    • ...
  • Nos detuvimos en arena y hablamos de:
    • Widgets como Button, TextBox, Label, Panel
    • Controllers como MessageSend
    • Binding sobre properties del modelo
    • Comparamos el codigo swt con la misma funcionalidad en Arena y observamos algunas cosas:
      • En Arena no definimos codigo para hacer conversiones del string que tiene el TextBox al double que usa el modelo
        • Hablamos brevemente de como se define un Adapter para el caso de conversiones mas complejas
      • En Arena tenemos bindings bidireccionales
      • Hablamos de los problemas de que muchos de los componentes que vimos, en especial en Java reciben strings que se linkean literalmente con propiedades o mensajes del modelo. Los strings no tienen información de su contexto por lo que si tipeamos mal o si renombramos y el string no coincide nada funciona y no nos damos cuenta hasta que estamos ejecutando
  • Después de mucho analizar hablamos de MVC, como patrón y de lo abstracto que es
    • La mayoria de los frameworks dicen ser MVC
    • Siempre tenemos que leer la letra chica e interiorizarnos en la interpretacion que tienen los que implementaron el framework
  • Exploramos alternativas al conversor
    • Sacamos el boton "Convertir a Kilometros" e hicimos que mientras tipeabamos las millas convirtiera solo a kilometros
    • Cambiamos el modelo, podemos convertir de millas a kilometros y de kilometros a millas.
    • Vimos una implementacion del conversor en Xtend
    • Pensamos en un conversor super genérico: queremos convertir de una unidad a otra
Algunas cosas que dijimos durante la clase:
Apuntes dentro del site que son de utilidad para leer en mas detalle:

1-5 of 5