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

Jueves 14/04/2011 - Continuación Web

publicado a la‎(s)‎ 18 mar. 2011 6:43 por Javier Fernandes   [ actualizado el 18 abr. 2011 14:42 por gisela decuzzi ]

De Html dinámico a Aplicaciones


Retomamos la idea de aplicaciones web.
Vimos que si bien uno puede escribir html manualmente, esto genera archivos estáticos. Donde el contenido sería el mismo para todos los usuarios y en diferentes pedidos que haga un mismo usuario en diferentes tiempos (hoy, mañana, el año que viene, etc.)

Esto presenta una limitación muy grande, obviamente, por lo que no nos permite hacer aplicaciones reales.

Entonces, para construir aplicaciones, es necesario hacer un programa, o una aplicación justamente, que genere ese html dinámicamente, con contenido actualizado / generado.

La forma tradicional y más básica de hacer eso en java es con páginas llamadas JSP y a través de un programa java ya existente llamado webserver.

Qué es un web server ??

Un webserver es:
  • un programa que escucha en un puerto dado (generalmente el 80 es el default):
  • entiende el protocolo HTTP (HyperText Transfer Protocol)
  • "sirve" contenido HTML.

Web servers en java

Como dijimos, el html por sí mismo es estático, entonces en el mundo java existe un concepto de webserver que permite tener aplicaciones "java web", que generan estos html dinámicamente.
Esta tecnología es un standard java definido por sun, y se llama "servlets". Y el web server se dice que es un "servlet container".

Un Servlet, es básicamente,
  • una clase java que implementa cierta interfaz,
  • entiende un pedido HTTP y genera una respuesta.
Por ahora, vamos a decir que los JSP's son algo parecido, solo que nos evitan escribir clases java o meter Strings con código html dentro de una clase java.


Servlets vs JSP

El servlet me permite escribir una clase java, y dentro generar html.
En cambio el JSP, a la inversa, me permite definir un archivo mayoritariamente html, y dentro, incluir algo de código java, para hacer la página dinámica.


Model 2

Tipo de arquitectura o convención para crear aplicaciones web, y estructurarlas de modo de:
  • que no quede un servlet con mucho código html.
  • que no quede un html con mucho código java.
La idea es que:
  • el servlet maneja la lógica:
    • de negocio: como por ejemplo, delegar en los objetos de negocio para buscar los Socios del videoclub.
    • de presentación: actúa de controller, manejando las cuestiones de navegación. Para eso, una vez ejecuta la lógica, redirecciona a un JSP, que...
  • el JSP actúa de "vista": específicando como será el html de resultado, y mostrando los resultados de la operación ejecutada por el servlet. Es decir, mostrando los objetos de negocio.

La intención de este modelo es decirse ser una especie de MVC, donde el servlet es el controller, el jsp es la vista, y el negocio las clases a las que delega el Servlet.
En la práctica este modelo es muy precario, para nosotros, para ser considerado un MVC, comparándolo, por ejemplo, con el modelo de MVC que vimos en una aplicación "cliente pesado", como cuando vimos Arena.


HTTP

Vimos algo de la interacción entre el browser y el server.

Que hay dos tipos de pedidos (requests):
  • GET: envía los parámetros como parte de la url. Por ej: http://www.miserver.com/miapp/miservlet?parametro1=valor1&parametro2=valor2
  • POST: envía los parámetros como cuerpo del paquete HTTP. Esto permite enviar más información, y en forma más "segura", ya que no es visible para el usuario del browser diréctamente.

Vimos que una limitación de esta arquitectura, y que está relacionada con el protocolo HTTP, es que "cada pedido es independiente del anterior".
Y, generalmente en las arquitecturas de aplicaciones web, esto implica que el server no tiene "memoria". Específicamente la arquitectura de servlets, maneja las instancias de cada servlet a su manera. No necesariamente va a existir una única instancia de cada servlet. El servlet container podría generar más de una instancia.
Con lo cual, vemos que eso se diferencia bastante con la idea que vimos en arena, donde cada pantalla estaba conectada directamente con nuestros objetos de negocio.

En este modelo, el servlet es como un "servicio web" de la aplicacion, por donde entran los pedidos de todos los usuario. Es "compartido" para todos ellos.
Entonces, esto hace que cada servlet no pueda saber información de cada usuario en particular.
Y esto nos lleva a separar la lógica (servlet) de los datos (estado de la aplicación, para cada usuario).


FORMS:

Vimos el ejemplo de la búsqueda de libros. En particular, cómo interactúa el browser con el server, para enviar los parámetros de búsqueda. Y como el servidor le responde.
Vimos un poco la estructura de las webapp. La idea de JSTL (Java Standard Tag Library), que permite utilizar tags especiales y además definir los nuestros propios.

Entonces, cómo manejo el estado ??

Session:

En el mundo de los servlets containers, existe entonces la idea de "sesion de usuario". Cada usuario (browser) va a tener una de estas sesiones única. La session es básicamente un mapa, donde vamos a poder agregar objetos nuestros, y recuperarlos.

Así, cada servlet que quiera realizar un comportamiento particular sobre objetos del usuario 'actual', va a tener que acceder a este "session".
Estos objetos que seteamos en la sesión se llaman "atributos".
Y es, además, una forma de mantener estado entre los diferentes servlets y páginas JSPs.

Request - Response:

De nuevo con el ejemplo de la búsqueda de libros, vimos que, una consecuencia de que cada pedido genere una página nueva es uno de los problemas más grandes de la programación web. Porque justamente, en este ejemplo, parecía que en la misma página se estaba actualizando solo el resultado.
Pero en realidad, por debajo, vimos que la respuesta era una página completamente nueva.

Algo importante, entonces es que todos los datos que el browser no envía al servidor, "se pierden".
Además, si el servidor (jsp + servlet), no se toma el trabajo de volver a escribir esos valores en cada control correspondiente (por ejemplo en un textbox), también se perdería!

Para formularios chicos esto no parece ser un gran problema.
Pero para aplicaciones con pantallas complejas y con muchos controles, representa un gran problema.


JSP:

Como acceder al estado desde el jsp ?

Usando EL (Expression Language), tenemos acceso a varios objetos "interesantes" para poder manejar el request.
Ej:
  • ${param} : acceso a los parámetros del request (serían los "campos" del formulario enviandos al submitearlo desde el browser). Ej: ${param.titulo}
  • ${sessionScope} : acceso a la session del usuario actual. Ej: ${sessionScope.libros}
  • ${request}: eso, acceso al request

Vimos que EL utiliza también la convención de Java Beans, esperando que las propiedades del objeto tengan accesors (getters & setters)

Expression Language Scopes:

Cuando escribimos una palabra en EL ${algo} esa palabra se intenta resolver contra un conjunto de scopes automáticamente.
Esto permite ahorrarnos escribir la ruta completa, por ejemplo ${sessionScope.atributo} como ${atributo}
Para esto, hay que entender que hay un "orden de resolución", desde el scope más particular al más general (o compartido).
  • page
  • request (sólo attributes)
  • session
  • application

Comments