II Curso Online JAVA-J2EE

Transcripción

1 II Curso Online JAVA-J2EE TEMA 4 Desarrollo web con las tecnologías J2EE Autor: PCYTA / Centro de Excelencia de Software Libre de Castilla-La Mancha Versión: 1.0 Fecha: Revisado :46 Licencia: CC-by-sa 2.5

2 0 Licencia Usted es libre de: Copiar, distribuir y comunicar públicamente la obra Hacer obras derivadas Bajo las condiciones siguientes: uso Reconocimiento. Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el que hace de su obra). Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor Nada en esta licencia menoscaba o restringe los derechos morales del autor. Para ver la licencia visite: 2

3 UNIDAD IV. DESARROLLO WEB CON LAS TECNOLOGÍAS J2EE 0 Licencia Estructura de una aplicación Web Componentes y contenedores Web Elementos de una aplicación web Desarrollo y despliegue de una aplicación web El fichero descriptor: Web.xml Servlet y JSP Servlet (básico) JSP (Básico) Request and Response Servlet (avanzado) JSP (Avanzado) JSTL Frameworks: Struts, JSF y Spring Patrón MVC Struts JSF Spring AJAX Introducción Principales elementos de AJAX Ejemplo de uso de AJAX Otras posibilidades ANEXO INSTALACIÓN DE TOMCAT INTEGRACIÓN DE TOMCAT Y ECLIPSE IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS

4 1 Estructura de una aplicación Web 1.1 Componentes y contenedores Web Como ya vimos en el Tema 3 de introducción a J2EE, la arquitectura J2EE define componentes y contenedores, en este tema veremos los Servlets y JSP que son componentes dedicados a la capa web. La siguiente figura (que ya vimos en el tema anterior) muestra donde están ubicados estos componentes: Tal y como hemos dicho las piezas fundamentales para la construcción de aplicaciones web con Java son los Servlets y los JSP, además, también se pueden usar los JavaBeans y las librerías de etiquetas (JSTL). Las aplicaciones web se despliegan en contenedores web, entre los más populares se encuentran: Tomcat ( que será el que utilizaremos en este curso, Caucho Resin ( y Jetty ( Los contenedores web se encargan principalmente de recibir las peticiones de los clientes remotos, dirigirlas a los componentes adecuados y devolver la respuesta generada, pero además se pueden encargar de la seguridad, controlar el acceso de los usuarios, gestionar el ciclo de vida de los componentes y un largo etcétera dependiendo de la implementación del contenedor. 4

5 1.2 Elementos de una aplicación web Una aplicación web se compone de los siguientes elementos: Componentes estáticos (ficheros html,css, javascripts, imágenes, etc). Servlets. JSPs. Clases de apoyo (Javabeans, POJOs, DAOs, etc) Librerías (ficheros JAR). Fichero descriptor del despliege (web.xml). Estos elementos tienen que organizarse dentro de una jerarquía de directorios predefinido en la especificación J2EE. La estructura mínima es la siguiente: Directorio raíz o padre (document root): será el que dé el nombre a la aplicación web. En este nivel de anidamiento se pueden encontrar los componentes estáticos y los JSPs, aunque se suelen crear subdirectorios para agrupar dichos elementos. Subdirectorio WEB-INF: en este directorio se debe encontrar el fichero descriptor web.xml. WEB-INF\classes: en este directorio se encuentran las clases de apoyo (ficheros *.class). WEB-INF\lib: aquí están las librerías (ficheros *.jar) que se utilizan en la aplicación, bien propietarias o de terceros. En la siguiente imagen podemos ver la estructura de un aplicación mínima que se llama HolaMundoServlet con un único Servlet: Las aplicaciones web las podemos encontrar dentro de los contenedores web (Tomcat) de dos formas distintas: 1. exploded o desempaquetadas, es decir, cada fichero se encuentra en cada directorio de forma separada siguiendo la estructura anteriormente mencionada; 2. packaged o empaquetadas, es decir, como un único fichero con la extensión WAR (Web Application Archive) que contiene toda la estructura mencionada (al igual que hacen los compresores o se realiza con los archivos JAR). Durante el desarrollo de las aplicaciones se suele trabajar con la primera forma y cuando la aplicación se pasa a entornos de producción se entrega como un solo fichero WAR. Los ficheros WAR se pueden crear mediante la herramienta jar que proporciona la JDK (jar cvf <nombreaplicacion>.war). También es algo que se puede realizar de forma automática mediante el IDE. 5

6 1.3 Desarrollo y despliegue de una aplicación web A continuación vamos a enumerar los pasos que es necesario llevar a cabo para desarrollar una aplicación web y posteriormente desplegar dicha aplicación en un contenedor web (Tomcat) para que sea accesible desde los navegadores. 1. Crear la estructura de directorios adecuada. Como ya hemos visto en el apartado anterior las aplicaciones web necesitan tener una estructura de directorios predefinida por lo que necesitaremos crear dicha estructura de directorios. También es recomendable, y así lo hacen la mayoría de IDEs por defecto, mantener separado las clases fuente de las clases compiladas, es decir, crear dos directorios principales para cada proyecto (los nombres son orientativos y pueden ser diferentes): src: mantiene el código fuente (ficheros.java) de los Servlets y las clases de apoyo. web: debajo de éste directorio se crea la estructura definida en el apartado anterior y donde se guardan los ficheros JSPs, el contenido estático y el fichero web.xml. En la siguiente imagen podemos ver en detalle la estructura que podría tener una aplicación web normal. 2. Implementación de la aplicación. Llevar a cabo el desarrollo del contenido estático y dinámico (JSPs, Servlets) que necesite la aplicación. Estos ficheros deberán ir en su directorio adecuado. En la figura anterior se ha creado el directorio JSP donde se guardarían los ficheros JSP. 3. Modificar el fichero web.xml. Una vez desarrollada la aplicación se debe crear el fichero descriptor web.xml. En este fichero se dan las instrucciones que necesita el contenedor web para poder desplegar correctamente la aplicación y ser capaz de recibir-ejecutar-responder correctamente las peticiones de los clientes remotos. Es un fichero XML cuyo contenido veremos en el apartado siguiente. 4. Compilar las fuentes. 6

7 Compilar los ficheros fuentes (Servlets y clases de apoyo). Los ficheros compilados (*.class) deben residir en el directorio WEB-INF\classes. Este proceso se puede realizar de forma automática mediante ANT (una herramienta similar al makefile), o bien, mediante el IDE. 5. Despliegue de la aplicación. Desplegar la aplicación en el contenedor web (Tomcat). Este proceso supone copiar el directorio de la aplicación web en el directorio webapps donde esté instalado el Tomcat. Como dijimos la aplicación se puede desplegar como directorio desempaquetado, o bien, como fichero WAR. 6. Probar la aplicación. Ahora sólo queda probar desde un navegador (Internet Explorer, Mozilla Firefox, etc) que la aplicación se ha desplegado correctamente y que el contenedor web es capaz de procesar correctamente las peticiones y devolver las respuestas adecuadas. DOCUMENT ROOT / CONTEXTO / PETICION HTTP Se denomina document root al directorio raiz de la aplicación web donde están contenidos todos los subdirectorios obligatorios (WEB-INF, web.xml, etc) y los ficheros desarrollados (JSPs, Servlets, contenidos estáticos). El contexto es el nombre del document root que identifica de una forma univoca a la aplicación web dentro de un contenedor web. La petición HTTP que se realiza desde el navegador cliente tiene la forma: El fichero descriptor: Web.xml El fichero web.xml es el encargado de configurar la aplicación web para que el contenedor sea capaz de resolver adecuadamente las peticiones HTTP. Este fichero distingue entre mayúsculas y minúsculas y, además, es importante el orden en que se encuentran las etiquetas XML. En dicho fichero XML se identifican las siguientes partes (vamos a resumir las más comunes): Prólogo: la cabecera de todo fichero XML. Para la especificación J2EE 1.3 es: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" " Rutas de alias: cuando un contenedor recibe una petición tiene que ser capaz de determinar que componente de que aplicación web debe responder. Este se realiza definiendo unas rutas de mapeo. Por ejemplo, a continuación definimos que la aplicación web tiene un Servlet llamado HolaServlet y que se mapea sobre la ruta <servlet> 7

8 <description>holaservlet</description> <display-name>holaservlet</display-name> <servlet-name>holaservlet</servlet-name> <servlet-class>holaservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>holaservlet</servlet-name> <url-pattern>/servlet/holaservlet</url-pattern> </servlet-mapping> Parámetros de inicialización para la aplicación web. Se definen con las siguientes etiquetas: <context-param> <param-name>nombrebasedatos</param-name> <param-value>oraclepruebas</param-value> </context-param> Filtros: definen que filtros (clases, código implementado) se deben aplicar a que peticiones y en que orden. Se definen con las etiquetas <filter> y <filter-mapping>. Referencias a recursos: son necesarios cuando los componentes web hacen referencias a recursos del entorno, por ejemplo, bases de datos. <resource-ref> <res-ref-name>jdbc/bookdb</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> </resource-ref> 8

9 2 Servlet y JSP 2.1 Servlet (básico) Para situar históricamente la creación de los Servlets tenemos que volver la vista hacia un origen de Internet donde todo el contenido que se podía ver en los servidores era estático, formado por páginas HTML interrelacionadas con hiperenlaces. Posteriormente, se implementa la mejora de hacer que los servidores web generasen contenido dinámico, es decir, que dependiendo de los parámetros que se enviasen a un servidor (usuario conectado, catálogo de productos elegido, etc) la respuesta se generase de forma dinámica y fuese diferente dependiendo de esos parámetros. Esta mejora implica que ya no sólo tenemos en el servidor páginas HTML fijas, sino que es necesario tener programas que generen este HTML con cada nueva petición. Surgen entonces los CGI que son los programas que generan el contenido dinámico y que se implementan en diversos lenguajes (C, Perl, Python, etc). Evidentemente, en Sun no se quedan atrás y definen una especificación que cumpla con el cometido de estas aplicaciones CGI. A estos programitas los denominan Servlets, en contraposición a los applets que son programitas que se ejecutan en el cliente, mientras que los Servlets se ejecutan en el servidor. Resumiendo, los Servlets son objetos de Java que siguen la especificación y el API correspondiente y que sirven para dar la capacidad de generar contenido dinámico a un servidor http. Veamos nuestro primer y sencillito ejemplo de Servlet, evidentemente hablamos del famoso 'Hola Mundo'. public class HolaMundoServlet extends HttpServlet { public void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html"); PrintWriter out = response.getwriter(); out.println("<html>"); out.println("<head><title>hola Mundo</TITLE></HEAD>"); out.println("<body>"); out.print(" HOLA MUNDO! "); out.print("la fecha actual es: " + java.util.gregoriancalendar.getinstance().gettime().tostring()); out.println(" </BODY>"); out.println("</html>"); out.flush(); out.close(); } } 9

10 Revisando el código tendríamos que darnos cuenta de: 1. Nuestro primer servlet y todos los servlets heredan de la clase HttpServlet. 2. Se implementan el método doget. Lo estudiaremos en el apartado tercero. 3. Ambos métodos tienen como parámetros dos objetos: request y response. Estos objetos están directamente relacionados con la petición al servidor y la respuesta devuelta por este. 4. En el objeto response se indica que la respuesta es un fichero html (response.setcontenttype("text/html")). 5. Al response se le pide una salida donde escribir (PrintWriter out=response.getwriter()). 6. En la salida vamos escribiendo código HTML (out.println("<html>")). 7. Y finalmente se cierra dicho fichero de salida (out.close()). Sencillo verdad? Ahora que ya empezamos a comprender los servlets puedes levantar el Tomcat que te has instalado y desde un navegador vuelve a revisar los ejemplos de servlets que vienen ( 2.2 JSP (Básico) Ya hemos visto que con los servlets se consigue mediante Java devolver contenido dinámico desde un servidor http a los clientes. Si seguimos con la visión histórica, una vez que se crearon los Servlets los programadores Java estarían muy emocionados por todas las posibilidades que ofrecían. Ahora bien, cuál es el problema más evidente que tienen los Servlets?. Piénsalo un rato vamos, quiero decir 30 segundos, pues es algo que salta a la vista. EXACTO! Que dentro de las aplicaciones se encuentra embebido el código HTML. No existe separación entre la parte de la presentación y la parte propia de programación de la lógica de la aplicación. Para aquellos que no vean claramente el problema os contaré como funcionan las cosas en el mundo laboral. En las empresas suele existir un departamento de diseño gráfico, estos se encargan de la parte visual y, normalmente, serán expertos en código HTML o, más bien, en Dreamweaver (es un departamento donde gustan los colores y en pocas ocasiones se da que les guste los unos y ceros, suelen ser licenciados en Bellas Artes). Y, por otro lado, tenemos el departamento de desarrollo, estos son expertos en programación y, normalmente, ven en monocromo y la calidad visual de sus diseños deja mucho que desear (nos importa más que funcione bien, solemos ser Ingenieros Informáticos). En casi todos los proyectos los diseñadores realizan la parte visual de un proyecto, el cliente lo aprueba y finalmente eso se traduce en una maqueta HTML que se pasa al departamento de desarrollo para que lo integre en la aplicación web. Si sólo tuviésemos Servlet, el programador cogería el HTML lo integraría dentro del código Java y ya sería una página dinámica. Ahora bien, qué pasa si hay que cambiar el diseño HTML? Quién y cómo se realizan las modificaciones? Sabiendo que cada departamento controla de una sola cosa, una solución estaría en juntar el diseñador con el programador para que éste le diga en que clases está el HTML de tal página que hay que modificar y así lo pueda ir cambiando el diseñador. Evidentemente, el diseñador ya no tendría la posibilidad de utilizar ninguna herramienta visual (como Dreamweaver) para ir realizando las modificaciones y para cada cambio hay que estar recompilando la clase para poder ver el resultado. Otra solución sería que el diseñador hiciese las modificaciones sobre la maqueta para ver el resultado rápidamente y una vez modificada, volver a pasar todo el código al programador para que volviese otra vez a meterlo en los Servlets (seguro que el programador se iba a poner muy contento). Finalmente, se puede optar a tener programadores con conocimiento de diseño HTML, 10

11 pero este caso no siempre se da. No os suena todo un poco engorroso y poco viable para conseguir hacer proyectos de una forma sencilla? Pues evidentemente la mejor solución es intentar mantener esos ficheros HTML con su aspecto prácticamente original, incrustándole pequeños trozos de código Java que hagan la página dinámica (esto lo haría el programador) y enseñar al diseñador que esa parte no la debe tocar e incluso decirle que con el Dreamweaver esa parte le va resultar invisible. Mantener el código HTML con el mínimo código Java posible y llevarnos la lógica de negocio a las clases (Servlets y clases de apoyo). Pues esto es lo que se consigue con los JSPs. Resumiendo: Mantener separadas la vista de la lógica de negocio. Simplificar el desarrollo de las aplicaciones web mediante JSP, Javabeans y librerías de etiquetas (JSLT). Facilitar las modificaciones visuales (HTML). Además, los contenedores web recompilan automáticamente los JSP cuando se realizan modificaciones sobre dichos ficheros. Veamos el ejemplo de HolaMundo ahora con JSP. <HTML> <HEAD><TITLE>Hola Mundo</TITLE></HEAD> <BODY> HOLA MUNDO! La fecha actual es: <%= java.util.gregoriancalendar.getinstance().gettime().tostring() %> </BODY> </HTML> Significa esto que los JSP son mejores que los Servlets y no debemos utilizar estos últimos?. Evidentemente no, en la práctica los que se hace es utilizar ambos, veremos como la tendencia actual es desarrollar las aplicaciones web siguiendo el patrón MVC (Modelo-Vista-Controlador) y los Servlets se encargan de hacer de controladores y los JSPs de implementar la vista. 2.3 Request and Response La siguiente figura representa el proceso de petición y respuesta HTTP que se trata con los Servlet (Request y Response): 11

12 En este proceso podemos distinguir tres aplicaciones: el navegador cliente o BROWSER (IE, Mozilla, Opera, etc), el servidor web o WEB SERVER (Apache, IIS, etc) y el contenedor de servlets o SERVLET CONTAINER (Tomcat, Resin, etc). Normalmente, los límites entre el servidor web y el contenedor web son muy difusos por encontrarse dichas aplicaciones, en la mayoria de los casos, en la misma máquina. A continuación vamos a aclarar los pasos que se llevan a cabo por cada una de las aplicaciones. El usuario desde su navegador hace la petición de una página y le sale el típico formulario de petición de datos para que se registre. Lo que tiene en frente es una página HTML con un formulario (FORM) que contiene campos de entrada de datos (INPUT) y un botón de enviar los datos (SUBMIT). 12

13 El usuario envía el formulario y el servidor web se encarga de recibir la petición http (HTTP REQUEST) y pasar dicha petición al contenedor de servlets que se encarga de crear un objeto que representa la petición http (HttpServletRequest) y una sesión (HttpSession) que sirve para identificar al mismo usuario durante toda la navegación. El contenedor se encargará de decidir que Servlet tiene que ejecutarse, para ello utilizará el fichero descriptor web.xml donde consultará que servlet se tiene que ejecutar según la ruta URL solicitada. Una vez identificado el servlet, realizará las tareas programadas, por ejemplo, comprobar que llegan todos los datos estan correctamente escritos en el formulario y si son correctos almacenar en la base de datos, ejecutando las clases adecuadas (el servlet y las clases que pueda ser invocadas desde el 13

14 mismo). Finalmente, en el servlet se creará la respuesta http (HttpServletResponse) que devolverá al navegador cliente a través del servidor web. Esta respuesta normalmente será una página HTML que en nuestro caso nos confirmaría el alta del registro del usuario. La siguiente tabla resume que es lo que contiene la petición (request) y la respuesta (response) HTTP: REQUEST La petición es la información que envía un cliente a un servidor, esta información incluye quién ha realizado la petición (dirección ip, tipo navegador, etc) y la información propiamente introducida por el usuario en el formulario. RESPONSE La respuesta es la información que envía el servidor al cliente. Se debe indicar que tipo de información se está devolviendo, si es texto (html, plain) o binario (imagen). Además, se devuelve también de cookies, headers, etc. La petición http se compone de: - header: información de quien envía la petición. - method: método de envío. Los dos más 14

15 conocidos son GET y POST, con el primero los datos enviados se añaden a la URL, con el segundo se envían como un dato. - request data: Los datos propiamente. 2.4 Servlet (avanzado) La siguiente imagen muestra la jerarquía de clases del API de Servlets en Java: Cuando creamos un nuevo Servlet heredamos de la clase HttpServlet. Tal y como hemos comentado en el apartado anterior, cuando llegan nuevas peticiones de un cliente, el contenedor crea los objetos HttpServletRequest y HttpServletResponse y pasa dichos objetos al método service() de la clase HttpServlet. Y finalmente, tenemos la clase HttpSession que se encarga de mantener información relacionada con la sesión. En la siguiente figura podemos ver los métodos que se implementan en un Servlet y el ciclo de vida que presentan dichos métodos dentro del contenedor: 15

16 El método init() se llamará una única vez cuando se crea una instancia del Servlet (por defecto, se crea una sola instancia de cada Servlet definido en el fichero web.xml en tiempo de despliegue de la aplicación web). Éste método sirve para realizar tareas de inicialización (por ejemplo, crear las conexiones a base de datos). El método service() se llama cada vez que llega una nueva petición y éste método invoca doget() o dopost() dependiendo del tipo de petición http que haya llegado. Es en estos métodos donde se programa realmente la aplicación. Dentro de las tareas que se llevan a cabo en dichos métodos podemos resumir: Extraer información enviada por el cliente (http parameter) de la petición http. Leer (get) o escribir (set) atributos en los Scope Objects (veremos que son a continuación). Llevar a cabo la lógica de negocio o el acceso a base de datos. Opcionalmente, redirigir la petición a otro componente web (Servlet o JSP). Crear el mensaje de respuesta http y enviarlo al cliente. Finalmente, cuando la instancia del Servlet se elimina (por quitar la aplicación web del contenedor o por detener el contenedor) se invoca el método destroy(). En éste método se llevan a cabo tareas de finalización (por ejemplo, cerrar conexiones a base de datos). Scope Objects. Se denomina Scope Objects a los objetos que permiten compartir información guardada en sus atributos entre distintos componentes de las aplicaciones web. Un ejemplo claro donde se utilizan este tipo de objetos es en una aplicación de comercio electrónico donde se está manteniendo durante toda la sesión de un usuario el carrito de la compra con la lista de los elementos seleccionados. Existen cuatro tipos de objetos predefinidos dependiendo del tipo de alcance (scope) que tengan: Web context o ServletContext (contexto): los objetos almacenados en éste alcance estarán disponibles por todos los componentes web dentro de una misma aplicación web. Session (sesión): el alcance de estos objetos es a nivel de la misma sesión. Request (petición): los objetos con este alcance se comparten por una misma petición. Page (página): los objetos están disponibles a nivel de página JSP. 16

17 Dentro del código de nuestras aplicaciones la forma de acceder a los valores guardados en estos objetos es idéntica, mediante el método setattribute() para almacenar valores y getattribute() para recuperarlos. HTTPSession. Vamos a hablar más detalladamente de los objetos que tienen el alcance de sesión por ser los que se utilizan más frecuentemente en las aplicaciones. Lo primero que debemos recordar es lo que ya se dijo en el primer tema del protocolo HTTP que es un protocolo sin estado. Las aplicaciones web utilizan este protocolo para realizar la comunicación entre cliente y servidor, para ello es necesario que se dote a los servidores con la capacidad de mantener la lista de peticiones sucesivas desde un mismo cliente simulando una sesión. Como antes dijimos, el ejemplo típico es una tienda de comercio electrónico donde es deseable que un usuario que se conecte a nuestra tienda tenga la sensación de que las peticiones no sean inconexas sino que formen parte de una misma sesión y así se pueda mantener el carrito de la compra durante dicha sesión. public class ComprarCarritoServlet extends HttpServlet { public void doget (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Recuperamos de la sesión del usuario el carrito de la compra HttpSession session = request.getsession(); ShoppingCart carrito = (ShoppingCart) session.getattribute ("carrito");... // Calculamos el precio total de la compra realizada por el usuario double total = carrito.gettotal(); } } Otro ejemplo muy recurrido es en las aplicaciones de banca donde se nos pide autenticarnos para poder recuperar nuestros datos bancarios. Si no mantenemos la información del usuario autenticado en la sesión, cada vez que tengamos que recuperar algún dato bancario (listado de cuentas, saldos, movimientos, etc) tendríamos que volver a solicitar que el usuario se autenticase. Sin embargo, lo normal es guardar en la sesión el identificador del usuario y en cada consulta recuperarlo de dicho objeto. 2.5 JSP (Avanzado) Tal y como dijimos en la introducción a los JSPs, la principal característica que presentan respecto a los Servlet es la separación entre la presentación y la lógica de negocio de la aplicación. En la siguiente figura vemos a la izquierda un Servlet donde la lógica de la aplicación y la presentación están juntos, a la derecha podemos ver como utilizando conjuntamente los Servlets con los JSPs mejoramos la aplicación dividiendo las tareas, pasando el Servlet a realizar tareas de controlador y dejando a la JSP la presentación. 17

18 LOS JSPs SON SERVLETS! Es importante reseñar que el contenedor (Tomcat) se encarga de coger cada JSP de las aplicaciones web, traducirlos y compilarlos generando los correspondientes Servlet y clases de forma transparente. Para comprobarlo, podemos ir al directorio donde tengamos instalado el Tomcat y revisar el contenido del directorio 'work' que es donde se generan dichos ficheros intermedios. Podemos ver que se han añadido los métodos init(), destroy() y service(), es decir, los mismos métodos que en los Servlets. Se tienen como parámetros del método service las instancias de los objetos request y response, y además, se crean variables que referencian a los Scope Objects comentados en el apartado anterior (pagecontext, session, application) y, por último, tenemos la variable out que referencia a la salida del response. Existen tres formas de añadir código Java en una JSP: 1. Expresiones: las expresiones JSP se utilizan para añadir el valor resultante de una expresión Java convertido a un string en la página HTML devuelta al navegador. El formato es <%= expresion %>. 2. Scriptlets: cuando se quiera introducir varias instrucciones Java se debe incluir dentro de estos bloques. El formato es <% código Java %>. 3. Declaraciones: estos bloques se utilizan para definir variables y métodos que vayan a ser 18

19 utilizados en el JSP. En éste código se realizan declaraciones para inicialización y finalización pues es código que se incluye en los métodos Init y Destroy. El formato es <%! Código declarativo %>. Javabeans. Los Javabeans son clases de Java que siguen una serie de reglas de diseño. Estas reglas están relacionadas con los atributos de la clase y los métodos de acceso a dichos atributos. Cualquier clase de Java que siga dichas reglas puede ser un Javabean. Los atributos de un Javabeans han de ser: Simples, es decir, tienen que contener un valor único o indexado dentro un array. De lectura/escritura, sólo lectura o sólo escritura. El acceso a dichos atributos se tiene que hacer definiendo métodos setxxx() y getxxx(), donde XXX es el nombre de un atributo. Además, si un Javabean implementa algún método constructor debe ser un constructor que no tenga ningún parámetro. Los Javabeans se pueden utilizar dentro de los JSP mediante etiquetas que permiten crear y acceder a los atributos de dichos objetos de una forma más sencilla que con scriplet. En el siguiente ejemplo podemos ver en la izquierda el código que se necesita para acceder al objeto del carrito de la compra que se encuentra en la sesión mediante scriplet y en la derecha el mismo acceso pero mediante el uso de etiquetas JSP para acceso a Javabeans. <% ShoppingCart carrito = (ShoppingCart)session.getAttribute("carrito"); // Si el usuario no tiene en sesión un objeto carrito es necesario crear uno nuevo. if (carrito == null) { carrito = new ShoppingCart(); session.setattribute("carrito", carrito); } %> <jsp:usebean id="cart" class="cart.shoppingcart" scope="session"/> 2.6 JSTL Asociado a los JSPs aparece las librerías de etiquetas JSTL (JavaServer Pages Standard Tag Library). Estas librerías de etiquetas encapsulan funcionalidades comunes que se realizan dentro de los JSPs, por ejemplo, en vez de mezclar código HTML con scriptlet para realizar un bucle y pintar una lista, se define una nueva etiqueta que realiza dicha labor. A continuación resumimos las ventajas que ofrece diseñar JSPs utilizando las librerías de etiquetas: No tenemos que escribir el código que encapsulan nosotros sino que es código implementado y probado (Reusabilidad). Sólo necesitamos aprender y utilizar un sencillo conjunto de etiquetas que vienen 19

20 proporcionadas por las plataformas J2EE. Estas etiquetas suelen estar más optimizadas que el código que nosotros implementásemos. Mediante la utilización de etiquetas la portabilidad de las aplicaciones JSP sigue manteniéndose. En la siguiente tabla se presentan los distintos grupos de librerías de etiquetas que nos podemos encontrar en la versión 1.1 de JSLT: Core (prefijo: c) XML (prefijo: x) Internationalization (prefijo: fmt) Database (prefijo: sql) Functions (prefijo: fn) Soporte de variables, control de flujo y gestión de URL. Control de flujo, transformaciones. Formateo de mensajes, números y fechas. Realización de consultas y actualizaciones SQL. Longitud de collections, manipulación de cadenas. En la siguiente tabla podemos ver en la izquierda una página JSP con scriptlet donde se muestra el contenido de una agenda de clientes y en la derecha el mismo resultado se obtiene utilizando las librerías de etiquetas. <%@ page import="com.cursojava.model.cliente, java.util.*"%> <p><h1>listado de clientes</h1></p> <% List agenda = (List)request.getAttribute("agenda"); Iterator agendaiter = agenda.iterator(); while(agendaiter.hasnext()) { Cliente cliente = (Cliente)agendaIter.next(); if( (cliente!=null ) && (cliente.getlastname()!=null) && (cliente.getnombre().length() > 0)) { %> <%=cliente.getnombre()%><br/> <% } else { %> INDEFINIDO<br/> <% } } %> <p><h5>última actualización: <%=new Date()%></h5></p> <%@ taglib prefix="c" uri=" %> <p><h1>listado de clientes</h1></p> <c:foreach items="${agenda}" var="cliente"> <c:choose> <c:when test="${not empty cliente.nombre}" > <c:out value="${cliente.nombre}"/><br/> </c:when> <c:otherwise> INDEFINIDO<br/> </c:otherwise> </c:choose><br/> </c:foreach><br/> <jsp:usebean id="now" class="java.util.date" /> <p><h5>last Updated on: <c:out value="${now}"/></h5></p> 20

21 3 Frameworks: Struts, JSF y Spring 3.1 Patrón MVC En este apartado vamos a estudiar el patrón MVC (Model-View-Controler), aunque ya se le dejó como tarea al alumno estudiar dicho patrón en el tema 1. Es necesario que el alumno comprenda perfectamente dicho patrón para poder entender la base en la que se fundamentan los frameworks que posteriormente se presentarán en esta lección. La siguiente figura muestra el patrón MVC, donde se pueden ver los componentes que lo integran y como interactúan entre ellos: Mediante este patrón se consigue definir una arquitectura de capas para una aplicación Web. La siguiente tabla resume las tareas que se llevan a cabo por cada componente del patrón: MODEL o capa de lógica de negocio VIEW o capa de presentación - Define los datos y la lógica de negocio de la aplicación. - En esta capa se llevan a cabo las consultas a BD, los procesos del negocio y las ordenes de procesamiento. - Nos encontraremos con los datos y el comportamiento que sea independiente de la presentación - Muestra la información según el tipo de cliente (HTML, XML, etc). - Presenta los resultados de la lógica de negocio - No trata como ni de donde se obtiene la información (esto es parte del modelo) 21

22 CONTROLLER - Se utiliza como conector entre la interacción del cliente y los servicios o capa ofrecidos por el servidor. controladora - Cuando se realiza una petición al controlador, éste decide quién va a gestionar dicha petición y que información se debe devolver. Este patrón no es exclusivo de las aplicaciones web sino que se puede utilizar en cualquier tipo de aplicación, téngase en cuenta que es un patrón de diseño aportado originariamente por el lenguaje Smalltalk para el desarrollo de aplicaciones con dicho lenguaje ( 3.2 Struts Struts es uno de los primeros frameworks que surgen para el desarrollo de aplicaciones web java siguiendo el patrón MVC. Es un proyecto open source que se encuentra desarrollado en Apache Jakarta ( Las características principales que presenta Struts son: Es un framework MVC. Se utiliza para construir aplicaciones web utilizando Servlets y JSPs. Esta desarrollado utilizando patrones de diseño (Singleton, composition view, delegate). Incluye un librería de etiquetas para facilitar el desarrollo de los JSPs. Struts está enfocado sobre todo en el Controlador, por eso se dice que es un framework independiente del Modelo y la Vista. Struts se integra con cualquier tipo de tecnología utilizada en el Modelo (JavaBeans, POJOs, EJBs, etc) y en la Vista (JSPs, JSTL, Velocity, etc) En la siguiente figura presentamos la estructura y el funcionamiento de Struts: 22

23 Paso 1. En este entorno, todas las peticiones que se realicen se deben corresponder con alguna acción que debe estar mapeada en el fichero de configuración XML de Struts (struts-config.xml). Ahí se especifican todas las relaciones entre acciones y clases, formularios y clases, acciones y jsps de presentación, que globalmente conforman el mapa de la aplicación. Pasos 2 y 3. Cuando la petición realizada implique el envío de un formulario por parte del cliente, en dicho fichero se podrá configurar una clase ActionForm asociada a dicha acción y si se debe realizar algún tipo de validación. Struts se encargará de recuperar los parámetros enviados, instanciar la clase ActionForm adecuada, poblar sus atributos (que deberán nombrarse igual que los parámetros) y realizar las validaciones adecuadas. Cuando todo sea correcto, Struts se encargará de pasar dicha instancia de ActionForm a la acción solicitada. Pasos 4, 5 y Una acción se corresponderá con una clase Java (heredera de la clase Action de 6. Struts). En este punto Struts se encarga de invocar el método perform() de dicha clase Action y será en esta clase donde se realizarán las acciones que se hayan implementado para llevar a cabo la lógica de negocio (guardar en BD un registro, consultar un listado de BD, enviar un de notificación, etc), bien en la propia clase o invocando los objetos de negocio correspondientes. Pasos 7, 8 y Una vez llevada a cabo la lógica de negocio, el controlador de Struts se encargará de 9. redirigir el flujo a la parte de la vista. Se invocarán el JSP asociado a la petición y se construirá la página de resultado utilizando si fuese necesario los datos proporcionados por los objetos de negocio, devolviendo dicha página al cliente. A continuación se indican como configurar los ficheros de una aplicación web para que se utilice Struts. Fichero descriptor web.xml Las aplicaciones desarrolladas con Struts son aplicaciones Web Java y, por lo tanto, tienen que seguir la estructura definida en apartados anteriores y también tendrán el fichero descriptor web.xml. En este fichero se necesita configurar la siguiente información: La definición y el mapeo URL del ActionServlet. Añadir el fichero de configuración de struts como parámetro de inicialización. (strutsconfig.xml). Definir la librería de etiquetas de Struts. Fichero configuración struts-config.xml Este es el fichero principal de Struts. En este fichero se encuentran las siguientes etiquetas XML que definen los siguientes elementos: <form-beans> contiene las definiciones de los FormBean (formularios) indicando el nombre y el tipo (nombre de la clase). <action-mapping> contiene la definición de las acciones. Se utiliza una etiqueta n <action> para cada una de las URLs que los navegadores pueden solicitar y quien será el Servlet (ActionServlet) encargado de responder a dicha petición. 23

24 <global-forwards> contiene la definición de los forwards comunes a toda la aplicación web. Formularios. En Struts se pueden utilizar dos tipos de formularios: ActionForm y DynaActionForm, que se definen en el fichero struts-config.xml. Con los primeros tenemos que crear clases que hereden de ActionForm y que únicamente tengan atributos y los métodos set y get de acceso a los mismo. Con el segundo tipo (DynaActionForm) no es necesario crear nuevas clases sino que en fichero strutsconfig.xml se listan los atributos o propiedades que lo componen y el tipo de cada propiedad. Para cada uno de los formularios definidos en struts-config.xml, el controlador de Struts realiza las siguientes tareas: Comprobar si el formulario (objeto) se encuentra en la sesión, en el caso de que no exista dicho objeto, se crea uno nuevo. Llamar a los métodos set del objeto formulario con cada parámetro de la petición cuyo nombre sea igual a alguna propiedad del formulario. Pasar el formulario con sus atributos actualizados como parámetro del método execute() de la acción que se haya invocado. Acciones. Las acciones en struts están enfocadas en desarrollar toda el flujo de control de la aplicación. Cuando el controlador principal de Struts recibe una petición, según la parametrización del fichero struts-config.xml redirige el flujo de control a la acción adecuada. La acción es una clase que hereda de org.jakarta.struts.action.action y que tendrá un método execute() donde se encontrará la lógica de negocio que tiene que llevarse a cabo (bien dentro de este ActionServlet o llamando a otras clases auxiliares). Finalmente, devuelve un objeto ActionForward que define el destino (JSP, otra accion, etc) donde debe dirigirse la ejecución. 3.3 JSF JSF (Java Server Faces) es el segundo framework que vamos a estudiar basado en el patrón MVC. Al igual que Struts, JSF pretende normalizar y estandarizar el desarrollo de aplicaciones web. Hay que tener en cuenta JSF es posterior a Struts, y por lo tanto se ha nutrido de la experiencia de éste, mejorando algunas de sus deficiencias. A continuación se presentan algunos de los puntos por los que JSF parece una tecnología muy interesante: Hay una serie de especificaciones que definen JSF:JSR 127, JSR 252, JSR 276. JSF trata la vista (el interfaz de usuario) de una forma similar al estilo de Swing, Visual Basic o Delphi (Drag & Drop), donde la programación del interfaz se hace a través de componentes y basada en eventos (se pulsa un botón, cambia el valor de un campo,...). JSF es muy flexible. Por ejemplo, nos permite crear nuestros propios componentes, o crear nuestros propios render para pintar los componentes según nos convenga. Luego no se limita a navegadores HTML. Es muy sencillo de utilizar pero sobre todo si se tiene un IDE que ofrezca esta capacidad. JSF no puede competir en madurez e integración en las aplicaciones actuales con Struts, pero si 24

25 puede ser una opción muy recomendable para nuevos desarrollos, sobre todo si todavía no tenemos experiencia con Struts. Aunque hay que tener claro que para poder explotar la verdadera potencia de JSF es necesario utilizar IDEs que proporcionen esta tecnología. En la siguiente imagen podemos ver la estructura y funcionamiento de JSF de forma sencilla. Como en otros frameworks basados en el patrón MVC, JSF tiene un servlet controlador que se denomina FacesServlet y que se encarga de recibir las peticiones y ejecutar las acciones definidas en el fichero de configuración faces-config.xml. Las páginas JSF se construyen como un árbol de componentes de Interfaz de Usuario (UI Components). Estos componentes se pueden asociar con un modelo de objetos denominado backing beans, estos objetos son los encargados de implementar la lógica de negocio, permitiendo mapear parámetros de la petición sobre atributos de estos objetos y eventos del cliente sobre sus métodos. Las respuestas se construyen cogiendo los componentes de Interfaz y transformándolos en un tipo de cliente particular (por ejemplo, o un navegador HTML o un navegador VML de un teléfono móvil). A continuación se indican como configurar los ficheros de una aplicación web para que utilice JSF. Fichero descriptor web.xml. En este fichero se necesita configurar la siguiente información: La definición y el mapeo URL del FacesServlet. Añadir varios parámetros del contexto. Fichero configuración faces-config.xml. Este es el fichero principal de JSF. En este fichero se encuentran las siguientes etiquetas XML que definen los siguientes elementos: <navigation-rule> contiene las reglas de navegación de la aplicación. Estas reglas determinan que página va después de que un usuario pinche un botón o un enlace. <managed-bean> contiene la declaración de los bean manegados o backing bean. Estos son objetos de la capa del modelo que mantienen datos, validaciones, gestiones de eventos y la lógica de navegación. Páginas JSF. La creación de las páginas es una tarea del desarrollador. Esta tarea implica definir los componentes UI que tendrá la página, mapear dichos componentes sobre el modelo de objetos (backing beans) y añadir, si es necesario, las llamadas a los eventos del modelo. 25

26 Backing beans u objetos del modelo. Como ya hemos dicho, los componentes de la Interfaz de Usuario (UI) se pueden mapear sobre las propiedades (atributos) de los objetos del modelo. Además, los eventos que se generan en los navegadores (pulsar un botón, cambiar el valor seleccionado de una lista, etc) también se pueden relacionar con métodos de dichos beans. 3.4 Spring Spring es un framework ligero que se puede utilizar tanto para desarrollar aplicaciones web J2EE como aplicaciones de escritorio Java. El objetivo de Spring es no ser intrusivo, es decir, aquellas aplicaciones configuradas para usar beans (clases) mediante Spring no necesitan depender de interfaces o clases propias del framework (como ocurre en Struts donde los formularios y las acciones heredan de clases de Struts) sino que la configuración particular de la aplicación se definirá en ficheros descriptores XML. De esta forma Spring permite que objetos del negocio y de acceso a datos sean reutilizables. Las características principales que proporciona Spring son: Gestión de configuración basada en JavaBeans, aplicando los principios de Inversión de Control (IoC). Esto hace que la configuración de aplicaciones sea rápida y sencilla. Un gestor de transacciones sencillo, permitiendo añadir nuevos gestores de transacción (pluggables), y haciendo sencilla la demarcación de transacciones sin tratarlas a bajo nivel. Se incluyen estrategias genéricas para JTA y un único JDBC DataSource. En contraste con el JTA simple o EJB CMT, el soporte de transacciones de Spring no está atado a entornos J2EE. Una capa de abstracción JDBC que ofrece una jerarquía propia de Excepciones, evitando la necesidad de obtener de SQLException los códigos que cada gestor de base de datos asigna a los errores, simplifica el manejo de errores, y reduciendo la cantidad de código necesario. Integración con Hibernate, JDO e ibatis SQL Maps en términos de soporte a implementaciones DAO y estrategias con transacciones. Especial soporte a Hibernate añadiendo convenientes características de IoC, y solucionando muchos de los comunes problemas de integración de Hibernate. Todo ello cumpliendo con las transacciones genéricas de Spring y la jerarquía de excepciones DAO. Funcionalidad AOP. Se puede aplicar AOP a cualquier objeto gestionado por Spring, añadiendo aspectos como gestión de transacciones declarativa. Un framework MVC (Model-View-Controller), construido sobre el núcleo de Spring. Este framework es altamente configurable vía interfaces y permite el uso de múltiples tecnologías para la capa vista como pueden ser JSP, Velocity,Tiles, itext o POI. De cualquier manera una capa modelo realizada con Spring puede ser fácilmente utilizada con una capa web basada en cualquier otro framework MVC, como Struts, WebWork o Tapestry. La arquitectura en capas de Spring ofrece mucha de flexibilidad. Toda la funcionalidad está construida sobre los niveles inferiores. Por ejemplo se puede utilizar la gestión de configuración basada en JavaBeans sin utilizar el framework MVC o el soporte AOP. 26

27 27

28 4 AJAX 4.1 Introducción A pesar de haberlo introducido en el tema 2, vamos a hacer un nuevo repaso de los conceptos en los que se basa AJAX. AJAX es una tecnología que se utiliza en las aplicaciones Web (en todas, no solo en J2EE), que ayuda a que las aplicaciones sean más rápidas, sencillas y "amigables" para el usuario. AJAX funciona en todos los navegadores "modernos", es decir, en versiones con pocos años de antigüedad. Esto es debido a que AJAX está basado en estándares que son implementados y "entendidos" por gran parte de los navegadores. En concreto, AJAX está basado en JavaScript, XML, HTML y CSS. Como decíamos en el tema 2, sin AJAX, si un usuario quiere hacer una petición al servidor, lo tiene que hacer mediante una petición GET o POST que implica que la página tiene que recargarse completamente. Usando AJAX, conseguimos hacer peticiones "en background" usando JavaScript y, al recibir la respuesta, tratarla sin necesidad de recargar la página. Esta comunicación con el servidor se hace mediante el objeto JavaScript XMLHttpRequest. AJAX no es mucho más que esto, en el resto de la lección vamos a ver los conceptos básicos y un ejemplo de uso. 4.2 Principales elementos de AJAX Como decíamos antes, la clave de AJAX es el objeto JavaScript XMLHttpRequest. Los distintos navegadores existentes (Internet Explorer, Mozilla FireFox, Opera, etc.) crean este objeto de diferentes formas, pero una vez creado el uso es el mismo. No olvidemos que AJAX es JavaScript, de modo que se ejecuta en el cliente (navegador). Para crear el objeto, hay que tener en cuenta al escribir nuestro código que puede ejecutarse en diferentes navegadores, de modo que la mejor forma de crearlo es mediante el uso de excepciones. El siguiente código es el que se suele usar: try { // Firefox, Opera 8.0+, Safari xmlhttp=new XMLHttpRequest(); 28

29 } catch (e) { // Internet Explorer 6.0 o superiores try { xmlhttp=new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { // Internet Explorer 5.5 o superiores try { xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { alert("your browser does not support AJAX!"); return false; } } } Con lo anterior ya tendríamos creado el objeto para enviar peticiones y gestionarlas con AJAX. Aún no estamos preparados para enviar la petición al servidor, antes tenemos que ver las tres principales propiedades del objeto XMLHttpRequest. - La propiedad onreadystatechange guardará la función que procesará la respuesta del servidor. - La propiedad readystate tendrá el valor del estado de la respuesta (response) del servidor. Los posibles valores de esta propiedad los vemos en la siguiente tabla: Estado Descripción 0 La petición no está inicializada 1 La petición ha sido preparada 2 La petición ha sido enviada 3 La petición está en proceso 4 La petición ha sido completada - La propiedad responsetext contendrá la respuesta del servidor. Con esto ya tendremos lo necesario para tratar la respuesta, pero nos falta lo necesario para enviar la petición. Para ello usamos los métodos "open" y "send" del objeto XMLHttpRequest. En el siguiente apartado vemos un ejemplo de código para asimilar los conceptos vistos hasta el 29

30 momento. 4.3 Ejemplo de uso de AJAX Una vez vistas las piezas clave de AJAX, llega el momento de ponerlas en práctica, para ello, vamos a crear una aplicación web muy simple con un "servlet" y con una "jsp". La idea de esta aplicación es que la "jsp" tendrá un campo para insertar un texto, en concreto una provincia y, cuando escribamos sobre ella, mediante AJAX se enviará una petición al servidor para que nos devuelva un texto con las provincias que empiecen igual que el texto que estamos introduciendo. El típico ejemplo para sugerir al usuario opciones. Esto es muy sencillo, solamente tenemos que crear una aplicación Web tal y como hemos visto en este tema (llamadla "cursoajax" y desplegadla en ese contexto para que el código que os pongo abajo os funcione a la primera). Luego cread una "jsp" directamente sobre "WebContent" llamada "index.jsp" y en el fichero dejad este contenido: <%@ page language="java" contenttype="text/html; charset=iso " pageencoding="iso "%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso "> <title>mi aplicación AJAX</title> <script type="text/javascript"> function mostrarsugerencia(dato) { if (dato=='') document.getelementbyid("sugerencia").innerhtml=''; else { var xmlhttp; try { // Firefox, Opera 8.0+, Safari xmlhttp=new XMLHttpRequest(); } catch (e) { // Internet Explorer try { xmlhttp=new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { alert("your browser does not support AJAX!"); return false; } 30

31 } } xmlhttp.onreadystatechange=function() { if(xmlhttp.readystate==4){ document.getelementbyid("sugerencia").innerhtml=xmlhttp.responsetext; } } xmlhttp.open("get","/cursoajax/miservlet?dato=" + dato,true); xmlhttp.send(null); } } </script> </head> <body> <form> Provincia: <input type="text" onkeyup="mostrarsugerencia(this.value)" id="provincia"> Sugerencia: <span id="sugerencia"><!-- aqui se meterá la respuesta del servidor --></span> </form> </body> </html> Luego cread un "Servlet" y llamadlo "MiServlet" en un paquete llamado "mipaquete". En este "Servlet" meted el siguiente código: package mipaquete; import java.io.ioexception; import java.io.printwriter; import java.util.hashmap; import java.util.map; import javax.servlet.servletexception; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; /** * Servlet implementation class for Servlet: MiServlet * */ public class MiServlet extends javax.servlet.http.httpservlet implements javax.servlet.servlet { static final long serialversionuid = 1L; static String[] provincias = {"Albacete","Madrid","Barcelona"}; /* (non-java-doc) 31

32 javax.servlet.http.httpservlet#httpservlet() */ public MiServlet() { super(); } /* (non-java-doc) javax.servlet.http.httpservlet#doget(httpservletrequest request, HttpServletResponse response) */ protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String sugerencia = ""; //aquí obtenemos lo que ha escrito hasta ahora el usuario String datoinsertado = request.getparameter("dato"); for (int i = 0; i < provincias.length; i++) { if (provincias[i].startswith(datoinsertado)) sugerencia += provincias[i]; } if (sugerencia.length()==0) sugerencia="no conozco ninguna provincia que empiece asi. OJO con las mayusculas"; response.setcontenttype("text/html"); PrintWriter out = response.getwriter(); out.print(sugerencia); out.flush(); out.close(); } } Y una vez echo esto, meted el mapeo para el servlet en el fichero "web.xml". Este fichero debería quedar así: <?xml version="1.0" encoding="utf-8"?> <web-app id="webapp_id" version="2.4" xmlns=" xmlns:xsi=" xsi:schemalocation=" <display-name>aplicacion ajax</display-name> <servlet> <description></description> <display-name>miservlet</display-name> <servlet-name>miservlet</servlet-name> 32

33 <servlet-class>mipaquete.miservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>miservlet</servlet-name> <url-pattern>/miservlet</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> Una vez hecho esto, si arrancamos el servidor y escribimos en un navegador la url se cargaría la página. Y si probamos a escribir en el cuadro de texto, tras cada pulsación se nos mostrará una sugerencia. Mi memoria no alcanzaba a recordar más provincias que "Albacete", "Madrid" y "Barcelona", y tened cuidado con las mayúsculas!!! Probad y mejorad el código! Bueno, pues con esto ya debería estar funcionando la aplicación. Ahora vamos a explicar un poco su funcionamiento (id mirando el código mientras vais leyendo las siguientes líneas): Gracias al evento "onkeyup", se llama la función javascript "mostrarsugerencia", pasándole como parámetro el valor introducido hasta el momento en el campo "provincia". La función javascript "mostrarsugerencia" obtiene el objeto apropiado según el navegador para usar AJAX, y después define la función que se ejecutará cuando haya cambios en el estado de la petición al servidor. Esta función simplemente escribe la respuesta recibida en el "span" que se definió a tal efecto. Tras la definición, se hace la petición a nuestro servlet pasándole el texto introducido hasta el momento. Cuando el "servlet" recibe la petición, calcula la sugerencia y la devuelve. Cuando es devuelta, el estado de la petición pasa a ser 4 ("request completada") con lo que se ejecuta la función javascript que hemos definido, actualizando así el valor contenido en el "span". Nos hemos comunicado con el servidor y actualizado nuestra página sin recargar!!!! Sencillo, no?. Y para que veáis las ventajas de AJAX, imaginad que lo tuvierais que hacer sin AJAX, y además pensad que la página es muchísimo más compleja y pesada que nuestra simple "index.jsp". 33

34 4.4 Otras posibilidades Ya hemos visto un ejemplito de uso básico suficiente para entender la utilidad de AJAX. Pero por supuesto existen muchos más aspectos interesantes y útiles en AJAX. Un enlace muy interesante y bastante didáctico para aprender más aspectos de AJAX es Supongo que ya estaréis enamorados de AJAX pero antes deberíais saber que también existen frameworks para usar AJAX que nos proporcionan más funcionalidades, simplifican nuestros desarrollos, mejoran la calidad, aumentan el rendimiento, proporcionan integración con otros entornos, etc. A continuación os pongo un par de ellos que he usado y son bastante útiles. - AjaxAnyWhere ( - DWR ( Y, por si no tenéis suficiente, aquí tenéis una página con un listado muy amplio 34

35 5 ANEXO 5.1 INSTALACIÓN DE TOMCAT Vamos a proceder a realizar la instalación del contenedor de Servlets Tomcat 6. Esta aplicación se puede descargar desde la siguiente dirección Podemos encontrarnos con la versión ejecutable o ZIP. La primera realizará la instalación mediante un Wizard y, además, configura un servicio de Windows para poder administra el servidor Apache. Con la versión ZIP no se configura ningún servicio de Windows y seremos nosotros los encargados de parametrizar adecuadamente la aplicación. A continuación vamos a mostrar una guía para instalar la versión ejecutable Una vez tengamos el instalable comenzaremos la instalación haciendo doble clic sobre el ejecutable. Lo primero que debemos hacer es aceptar la licencia que se nos presenta (I Agree): Seleccionamos el tipo de instalación del servidor que se va a realizar, ampliamos la normal para que incluya también los ejemplos (examples): 35

36 Decidimos el directorio en que va a ser instalado el programa: Se solicita los parámetros de inicialización del servidor, donde tenemos que decidir el puerto donde va a escuchar el servidor (8080 por defecto, pero se puede seleccionar cualquier otro que este libre) y el usuario y password que se utilizará para la aplicación de administración del servidor. 36

37 Ahora nos solicita que le indiquemos la ruta donde tenemos instalada la Java Runtime (JRE) e iniciamos la instalación pulsando el botón de Install. Completada la instalación pinchamos en Finish. 37

38 Se ha finalizado con la instalación y comprobamos el acceso en el menú de inicio que se ha creado para administrar el servidor Tomcat. Pinchando en Configure Tomcat. Nos aparece una ventana para poder administrar el servidor Tomcat que se ha instalado como un servicio de Windows. Desde esta ventana podemos configurar el servicio de Windows para que se arranque de forma manual, automática o deshabilitarlo. Si pinchamos en Start arrancamos el servidor de Tomcat. 38

39 Podemos comprobar que se ha arrancado correctamente y podemos tener acceso a la herramienta de administración, a la documentación y a los ejemplos conectándonos a la dirección con nuestro navegador (IE, Mozilla, etc). 39

40 Pasamos a continuación a explicar como realizar la instalación de la versión ZIP del instalable del Tomcat. Descomprimimos el fichero en el directorio donde deseamos tener la aplicación. Y podemos ver las carpetas que componen el instalable. Abrimos una ventana de comandos, nos situamos en el directorio bin e intentamos lanzar el tomcat con la llamada a startup. Vemos que nos da un error y nos pide que se definan las variables de entorno JAVA_HOME O JRE_HOME. Configuramos la variable JAVA_HOME para que apunte al directorio donde 40

41 tengamos instalado la JDK 1.5. Volemos a llamar a startup para que arranque el Tomcat y si todo es correcto, abre otra ventana de comandos donde tendremos el log del Tomcat. Al igual que para la versión ejecutable, para comprobar que se ha arrancado correctamente nos conectamos a la dirección con nuestro navegador (IE, Mozilla, etc). 41

42 5.2 INTEGRACIÓN DE TOMCAT Y ECLIPSE Ya tenemos instalado en nuestro ordenador el Tomcat y funciona correctamente. Vamos a ver como se integra dentro de nuestro entorno de desarrollo Eclipse. Arrancamos el Eclipse y nos vamos a la opción de menú Window -> Preferences Dentro de la ventana de Preferences, seleccionamos la opción Server -> Installed Runtimes y dentro de esta ventana es donde se gestionan los servidores de aplicaciones instalados. Pinchamos en el botón Add para añadir y configurar nuestro servidor Tomcat: 42

43 Desplegamos la carpeta de Apache y seleccionamos la versión de nuestro Apache Tomcat : Pinchando en el botón de Browse seleccionamos el directorio donde hayamos instalado nuestra versión del Tomcat y del desplegable debemos seleccionar la JRE/JDK con la que queremos que se despliegue el servidor: 43

44 Pinchando en Finish terminamos la instalación y configuración del Tomcat dentro del Eclipse y podemos ver como se ha añadido dentro de los servidores instalados: Volviendo al Eclipse, en la vista Servers podemos ver como aparece el servidor Tomcat que hemos configurado. Pinchando con el botón de la derecha aparece el menú emergente que nos permitirá administrar dicho servidor: 44

45 Si pinchamos en la opción Start iniciamos dicho servidor y podemos ver el log que devuelve dicho servidor para notificarnos que está arrancado correctamente y en que puerto está escuchando (8080): 45

46 5.3 IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS A continuación vamos a detallar los pasos que hay que llevar a cabo para importar, configurar y poner en funcionamiento la primera aplicación web con Struts dentro de nuestro entorno de desarrollo Eclipse. Lo primero es descargar dicho proyecto de aquí. Descomprimir dicho fichero en un directorio temporal. Iniciamos el Eclipse y pinchando con el botón de la derecha sobre la vista de Project Explorer nos vamos a la opción Import > Import: En la ventana de Import, desplegamos la carpeta General y pinchamos sobre la opción Existing Projects into Workspace : 46

47 En esta ventana tenemos que buscar (Browse) el directorio donde hayamos descomprimido el fichero struts-registration.rar. Una vez seleccionado nos aparece el proyecto struts-registration, lo marcamos con el check y pinchamos el botón de Finish: Una vez importado el proyecto nos aparece en la vista de Project Explorer. Como en mi caso es probable que aparezca marcado con la cruz roja de tener problemas con la compilación: 47

48 Para solucionar el/los problemas que existan, pinchamos con el botón de la derecha del ratón sobre el proyecto y pinchamos en la opción de Properties, nos aparece la ventana de propiedades del proyecto donde se configuran diferentes opciones siendo las principales la dependencia de librerías (Java Build Path), otros proyectos de los que dependa (Project Referentes), el context root (Web Content Settings) o el servidor donde se va a desplegar el proyecto: Podemos ver que en el Build Path nos indica con un aviso que la librería de la JRE no la encuentra. Lógico! Es poco probable que vosotros y yo tengamos configurado en el Eclipse las versiones de la 48

49 JDK/JRE idénticas y con el mismo nombre. Para arreglar dicho problema pinchamos sobre dicha librería y en el botón de edit : Seleccionamos la JRE que tengamos en nuestro Eclipse y finalizamos y cerramos la ventana de propiedades, lo que provoca que se recompile el proyecto y desaparezcan los problemas (ya no tenemos la marca roja). También podrían aparecer problemas relacionados con las versiones del Tomcat que se solucionan de idéntica forma. Si echamos un vistazo a la aplicación web que habeís importado es una aplicación con Struts muy sencilla que prácticamente consiste en un formulario para registrarte donde se pide el nombre, dirección, edad y teléfono, siendo campos obligatorios el nombre y la edad. Si todo es correcto y la edad introducida es mayor de 18 años te notifica con que el registro ha sido correcto sino te informa que sólo pueden registrarse mayores de 18 años. Veamos como desplegar dicha aplicación con Eclipse en el Tomcat que tenemos instalado. Tenemos dos opciones para levantar el Tomcat: en modo ejecución y en modo debug, que no necesitan más explicación para toda persona que haya programado alguna vez con un entorno de desarrollo. Arrancamos en modo ejecución normal: 49

50 Nos indica que seleccionemos el servidor Tomcat donde se va a desplegar el proyecto, seleccionamos el Tomcat 6 y marcamos que siempre use este servidor: Pinchamos en Next y nos muestra la pantalla con las aplicaciones web disponibles en el Eclipse para que pasemos al lado de la derecha aquellos que queramos que se desplieguen en el servidor (debe aparecer el struts-registration): 50

51 Pulsamos Finish, se arranca el servidor Tomcat y nos inicia el navegador web configurado (en la imagen se ha iniciado el navegador interno que incluye el Eclipse): 51

52 Se propone al alumno que pruebe la aplicación web estudiando como se lleva a cabo con Struts la validación del formulario, la configuración de las acciones en el struts-action.xml, la clase que implementa la acción de registrar (RegistrarAction) o la internacionalización de la aplicación (español, inglés). Podeís hacer modificaciones sobre el código y realizar traceo del código mediante breakpoints (modo debug). La segunda aplicación que se va a estudiar es con el framework JSF y es un ejemplo que viene con la distribución de J2EE de Sun, para descargarla pincha aquí. Consiste en un formulario que te pide que adivines el número que está pensando Duke (un valor entre 0 y 10). Es una aplicación muy sencilla y que sirve para ver como configurar y relacionar formularios con backing beans en JSF, como se configuran los JSP con los componentes UI de JSF y como se define la navegación. Los pasos que se tienen que realizar para importar, compilar y desplegar la aplicación son similares a los llevados a cabo con el ejemplo de Struts. La única diferencia esta en que esta aplicación se recomienda que se despliegue en el servidor Tomcat 5.5 que los alumnos ya tendrían que tener instalado e integrado en Eclipse. La aplicación también funciona sobre Tomcat 4.1 pero se obtienen trazas de error continua por temas de XML. Al igual que con el ejemplo de Struts, probar la aplicación, tracearla, modificarla, etc... con el objetivo de que el alumno sea capaz de controlar dicho tipo de aplicaciones y frameworks pues serán la base para los ejercicios que se proponen en el tema y éste tema se considera uno de los más importantes de cara a la preparación para el mundo laboral. Como último ejemplo, vamos a ver que pasos hay que llevar a cabo para poder importar en Eclipse un proyecto que no se haya realizado con dicho IDE, por ejemplo, porque lo hayamos bajado de Internet o venga en algún tutorial que estemos leyendo. Para este caso, la aplicación que tenemos te la puedes descargar de aquí. 52

53 Una vez que descomprimas el fichero podrás comprobar que en la estructura de subdirectorios encontramos lo siguiente: build: no tiene contenido. dist/lib: archivo banking.war. lib: librerías o archivos.jar. META-INF: sin contenido. src: dentro de las subcarpetas correspondientes (paquetes) se encuentran los archivos.java. web: con la estructura obligatoria de una aplicación web Java, encontramos dentro imágenes, JSPs, web.xml y fichero de estilos. Vamos a ver como encajamos estas piezas dentro de un proyecto de Eclipse. Lo primero es crear un nuevo proyecto web (Dynamic Web Project) en Eclipse con el nombre de banking, para esto podemos seguir el ejemplo de HolaMundo que ya hemos visto en el tema 4. Una vez creado el proyecto banking, nos vamos a ir a una ventana del explorador de Windows y vamos a ir copiando desde las carpetas anteriores hasta la ruta donde se encuentra nuestro proyecto banking en el workspace del Eclipse. En la siguiente imagen podemos ver que la intención es copiar desde el explorador de la izquierda (donde tenemos descomprimido el banking-dev.zip) en el explorador de la derecha (donde se encuentra nuestro proyecto banking creado con Eclipse). Tenemos que copiar el contenido de las siguientes carpetas: del src (zip) al src (eclipse); del web (zip) al WebContent (Eclipse), pregunta si sobreescribe y confirmamos la sobreescritura del contenido; del lib (zip) al WebContent/WEB-INF/lib. Una vez que lo tenemos todo copiado, volvemos a Eclipse y refrescamos el proyecto (F5), debería recompilarse el proyecto con los nuevos fuentes que hemos copiado desde el explorador de Windows. Y ahora ya podemos desplegar la aplicación banking en el Tomcat mediante el run on server. 53