Introducción a JSP (Java Server Pages)

Las JavaServer Pages (JSP) nos permiten separar la parte dinámica de nuestras páginas Web del HTML estático. Básicamente, conseguimos incrustar código java dentro de un documento HTML cuya extensión ha de ser *.jsp.
Hay tres tipos de construcciones JSP que embeberemos en una página: elementos de script, directivas y acciones. Los elementos de script nos permiten especificar código Java que se convertirá en parte del servlet resultante, las directivas nos permiten controlar la estructura general del servlet, y las acciones nos permiten especificar componentes que deberían ser usuados, y de otro modo controlar el comportamiento del motor JSP. En el siguiente enlace podemos ver una tabla detallada de estas construcciones.
En el modelo MVC, JSP conformaría la vista de nuestra aplicación. En el siguiente tutorial se muestra más detalladamente la especificación JSP:
- Tutorial Servlets y JSP

Patrón de diseño Controlador Frontal

¿QUÉ ES UN PATRÓN DE DISEÑO?

Los patrones del diseño tratan los problemas del diseño que se repiten y que se presentan en situaciones particulares del diseño, con el fin de proponer soluciones a ellas. Por lo tanto, los patrones de diseño son soluciones exitosas a problemas comunes.

¿QUÉ ES EL PATRÓN CONTROLADOR FRONTAL (FRONT CONTROLLER)?

Es un patrón de diseño que se basa en usar un controlador como punto inicial para la gestión de las peticiones. El controlador gestiona estas peticiones, y realiza algunas funciones como: comprobación de restricciones de seguridad, manejo de errores, mapear y delegación de las peticiones a otros componentes de la aplicación que se encargarán de generar la vista adecuada para el usuario. La siguiente figura muestra un esquema de ello:



Ventajas:

• Tenemos centralizado en un único punto la gestión de las peticiones
• Aumentamos la reusabilidad de código
• Mejoramos la gestión de la seguridad

Desventajas:

• La velocidad de respuesta disminuye al tener que ser procesadas las peticiones primero por el controlador.

En el siguiente enlace se puede ver una explicación más detallada de este patrón.

Métodos forward(), include(),init() y sendRedirect()

INTRODUCCIÓN

Un servlet/JSP puede invocar de modo directo a un recurso de la web. La idea es poder reenviar la petición (request) a dicho recurso. Para hacer esto necesitamos un RequestDispatcher, que es un referencia que encapsula el recurso. En el siguiente ejemplo (véase la clase PruebaDispatcher) el servlet tiene como "dispatcher" otro servlet (sc es un ServletContext que se obtiene en init()):

RequestDispatcher dispatcher = sc.getRequestDispatcher("/requestimagen");

Observar que el argumento corresponde con el url-pattern de web.xml. La creación del dispatcher se podría escribir de otra forma:

ResquestDispatcher dispatcher = request.getRequestDispatcher("/requestimagen");

Pero se puede observar que este método en ocasiones falla y la documentación de Sun recomienda la primera forma: sc.getRequestDispatcher(arg). El argumento es la ruta del recurso, que debe comenzar con "/" y es interpretado como relativo al contexto actual. Conviene usar getContext() para obtener un RequestDispatcher de recursos en contextos externos.
getRequestDispatcher(arg) retorna null si el ServletContext no puede retornar un RequestDispatcher.

La invocación al recurso se puede hacer de dos formas:

• Incluir el recurso en el flujo de salida. La salida de "/requestimagen" se incluye en la salida del primer servlet.

dispatcher.include(request, response);

• Redirigir (forward) la petición al recurso. Funcionalmente semejante a sendRedirect(). Se trata de redirigir la petición a otro componente:

dispatcher.forward(request, response);

La diferencia entre sendRedirect() y forward() (o también include()) es:

• En sendRedirect() la petición acaba bajo el control del segundo servlet. La URL que se puede ver en el navegador es la del segundo servlet. Además sendRedirect() es un método de HttpResponse
  

• En forward() o include() la petición se controla por el primer servlet. La URL que se puede ver en el navegador es la del primer servlet.

Aquí se puede ver el código de las clases PruebaDipatcher y RequestImagen.

Filtros

¿QUÉ SON LOS FILTROS?

Los filtros son clases que nos permiten realizar ciertas operaciones sobre una petición (HttpServletRequest) antes de ser entregada al servlet destino y de la misma manera nos permite realizar ciertas operaciones sobre la respuesta (HttpServletResponse) de un servlet antes de ser entregada al cliente. La siguiente figura nos muestra dicho proceso:



Hay que tener en cuenta que:

• Podemos tener más de un filtro para procesar la petición dispuestos en cadena
• Un mismo filtro puede atender las peticiones de más de un servlet
• Un filtro puede procesar únicamente la petición o únicamente la respuesta

¿QUÉ ACCIONES PODEMOS REALIZAR EN UN FILTRO?

Los filtros nos pueden permitir verificar los datos que el usuario envía a la aplicación, darle un formato determinado a esos datos, desviar la petición a otro servlet para que la procese antes de enviar la información al servlet destino, darle formato a la respuesta que envía el servlet, modificar convenientemente la respuesta de un servlet (por ejemplo una imagen, un fichero pdf, etc), etc. Hay dos importantes ventajas que nos ofrecen los filtros:

• Descarga al servlet de realizar ciertas tareas relacionadas con la petición y la respuesta
• Si está adecuadamente diseñado, nos permite reutilizar ese filtro en distintas aplicaciones

¿CÓMO SE CREA UN FILTRO?

• Creamos una clase que implemente la interfaz javax.servlet.Filter
• Implementamos sus métodos
• Damos de alta el filtro en el fichero web.xml
  

Uso de Listeners

¿QUÉ ES UN LISTENER?

Un Listener (o escuchador) es una clase que implementa la interfaz Listener y que nos permite realizar ciertas acciones ante un evento determinado. Los eventos que atiende un escuchador son:

• Cuando se inicia la aplicación (se crea el objetos ServletContext) y cuando se termina
  
• Cuando se inicia una sesión (se crea un objeto HttpSession) y cuando se cierra
  
• Cuando se realiza una petición (se crea un objeto HttpServletRequest) y cuando se destruye
  

La siguiente figura muestra el evento que produce cada objeto y el escuchador que atiende a dicho evento:



¿QUÉ ACCIONES PODRÍAMOS REALIZAR ANTE ESTOS EVENTOS?

Los escuchadores nos permiten inicializar las varibles de aplicación comunes a todos los usuarios (ServletContextListener), inicializar variables de sesión para un usuario (HttpSessionListener), hacer comprobaciones sobre los datos que el usuario envía a la aplicación (ServletRequestListener) o cualquier otra acción que necesitemos.

¿CÓMO SE CREA UN LISTENER?

• Creamos una clase que implemente la interfaz Listener
• Implementamos sus métodos
• Lo damos de alta en el fichero web.xml
  

Esctructura de directorios de una aplicación web

Una aplicación web desarrollada en java tiene una estructura similar a la siguiente:

aplicacion/
.../archivo.html
.../archivo.jsp
.../img/archivo.png
.../css/archivo.css
.../html/otro.html
.../jsps/otro.jsp
-------------------------------------------------------
Las carpetas y documentos anteriores conforman el contenido accesible desde el navegador
-------------------------------------------------------
.../WEB-INF/web.xml(Archivo de despliegue de la aplicaión)
.../WEB-INF/classes/es.cea...(Aquí van las clases de nuestra aplicación)
.../WEB-INF/lib/libreria.jar(Aquí van las librería necesarias para la aplicación)

Colecciones de objetos

Java nos provee de distintos tipos de estructuras para almacenar colecciones de objetas y poder operar sobre dichas colecciones. Entre los más importantes nos encontramos con las listas (List), los mapas (Map) y los conjuntos (Set). Los conjuntos se diferencian de los otros dos en que no pueden tener elementos duplicados (aquí entra en juego la sobreescritura del método equals() para determinar la duplicidad de los objetos).
En los servlets podemos usar el método println(variable_estructura) para imprimir todos los objetos que contiene la estructura (aquí interviene la sobreescritura del método toString() de los objetos almacenados). La forma en que se imprimen es entre corchetes y separados por comas los distintos objetos:

[objeto1,objeto2,...,objetoN]

Introducción a las sesiones en los Servlets

Para poder obtener un objeto HttpSession recurrimos al método getSession() del objeto HttpServletRequest. De este modo podemos crear variables de sesión mediante el método setAttribute(clave,valor) del objeto HttpSession y acceder a esas variables con el método getAttribute(clave). El método getAttribute(clave) devuelve un objeto de tipo Object así que es necesario hacer casting al tipo adecuado cuando recuperamos la variable. Ejemplo:

HttpServletRequest req;
req.getSession().setAttribute("nombre","raul"); //Declaramos la variable de sesión
String nombre=(String)req.getSession().getAttribute("nombre"); //Recuperamos la variable

Introducción a los Servlets

Un servlet no es más que una clase java capaz de procesar peticiones http por parte de un cliente. Para crear un servlet seguimos los siguientes pasos:

1- En Eclipse, dentro de nuestra aplicación web, en JavaResources: src creamos un nuevo paquete y le damos el nombre que queramos p.e. es.cea
2- Dentro de ese paquete creamos nuestra clase Servlet p.e. Saludo
3- Esa clase debe heredar de HttpServlet y sobreescribir los métodos doGet() y doPost(). Estos métdos se encargan de realizar las operaciones necesarias como respuesta a la solicitud.

¡¡Truquito!!
Cuando heredamos una clase o implementamos una interfaz, podemos ahorrarnos escribir el código de los miembros que queremos sobreescribir de la siguiente manera.
- Abrimos el menú contextual dentro del cuerpo de la declaración de la clase
- Elegimos la opción Source->Override/Implements Methods
- Nos sale un cuadro de diálogo con todos los métodos disponibles
- Marcamos los que queremos implementar y aceptamos
- Ahora aparce en nuestra clase el código con los métodos.

4- Editamos el fichero web.xml de nuestra aplicación y damos de alta nuestra clase en Tomcat.

Procesar peticiones en JSP

CREAR PROYECTO DE TRABAJO

Para la clase de hoy se creará un nuevo proyecto en Eclipse:
1- Crear un nuevo proyecto web dinámico llamado cea01.
2- Creamos dentro de WebContent el fichero bienvenida.jsp
3- Desplegamos el fichero en Tomcat
4- Accedemos a la URL http://localhost:8090/cea01/bienvenida.jsp para comprobarlo.

TEORIA: OBJETOS IMPLÍCITOS EN JSP Y SERVLETS



Los objetos mostrados en la anterior tabla son implícitos ya que no es necesario instanciarlos, la máquina virtual se encarga de ello, y así podemos hacer un uso directo de sus métodos y atributos. Cada uno de esos objetos se utilizan dentro de un contexto:

A) EVENTO

Un evento es toda acción que el usuario realiza sobre nuestra página y que genera URL más sus parámetros (si los hay), es decir, pulsar sobre un botón, un enlace, escribir directamente una URL, enviar un formulario,etc. Los eventos son manejados en JSP mediante el objeto request. El esquema siguiente muestra dicho proceso:




De esta manera, cada vez que se genera un evento, se crea un nuevo objeto request que se encarga de procesar dicho evento y que se destruye en el momento que procesa los datos que recibe. Para procesar los datos tenemos dos métodos:

-String getParameter(String parámetro): nos devuelve el valor del parámetro indicado
-String getRequestURL(): nos devuelve la URL que recibe los parámetros(el fichero)

Para entender estos dos métodos hay que tener en cuenta que el formato de petición de una URL con parámetros es: url_destino?parametro1=valor1&parametro2=valor2&... Por ejemplo:
bienvenida.jsp?nombre=raul&edad=27. Usando los dos métodos mencionados obtendríamos:

getParameter(“nombre”) devuelve “raul”
getParameter(“edad”) devuelve “27”
getRequestURL() devuelve “bienvenida.jsp”



B) SESIÓN

Este contexto se produce desde que un usuario accede a nuestra aplicación hasta que la abandona. Las sesiones son procesadas en JSP mediante el objeto session. Por tanto, se creará un nuevo objeto session por cada usuario que acceda a la aplicación y se destruirá dicho objeto cuando el usuario abandone la aplicación. Con respecto a esto hay que tener en cuenta que si un usuario accede a una aplicación desde dos navegadores distintos se crean dos sesiones ya que el usuario de nuestra aplicación es el programa navegador y no la persona que lo utiliza. En resumen, el objeto session nos permite encapsular aquellos recursos que podamos necesitar durante la sesión. Para ello tenemos los siguientes métodos:

-void setAttribute(String clave,String valor): definimos un parámetro y su valor
-String getAttribute(String clave): obtenemos el valor de un parámetro

C) APLICACIÓN

Este contexto se produce por la propia aplicación en sí y se mantiene mientras la aplicación se ejecute en el servidor. Por tanto, sólo hay un objeto application por cada aplicación. Este objeto encapsula todos los recursos necesarios durante la ejecución de nuestro programa.

EN RESUMEN:

- Los recursos comunes a todos los usuarios son manejados por application
- Los recursos comunes a un usuario durante su sesión son manejados por session
- Los recursos propios de un evento son manejados por request
- Sólo hay un objeto application por cada aplicación
- Hay un objeto session por cada usuario de la aplicación
- Se genera un objeto request por cada evento