SlideShare ist ein Scribd-Unternehmen logo
1 von 53
Downloaden Sie, um offline zu lesen
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 07-02-2008 11:46
Licencia: CC-by-sa 2.5
0 Licencia
Usted es libre de:
      Copiar, distribuir y comunicar públicamente la obra

       Hacer obras derivadas
Bajo las condiciones siguientes:
       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
uso    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:
http://creativecommons.org/licenses/by-sa/2.5/es/legalcode.es




6 de febrero de 2008                            Tema 4                                                  2
UNIDAD IV. DESARROLLO WEB CON LAS TECNOLOGÍAS J2EE

0 Licencia............................................................................................................................................2
1 Estructura de una aplicación Web................................................................................................4
  1.1 Componentes y contenedores Web............................................................................................4
  1.2 Elementos de una aplicación web..............................................................................................5
  1.3 Desarrollo y despliegue de una aplicación web........................................................................6
  1.4 El fichero descriptor: Web.xml..................................................................................................7
2 Servlet y JSP...................................................................................................................................9
  2.1 Servlet (básico)..........................................................................................................................9
  2.2 JSP (Básico).............................................................................................................................10
  2.3 Request and Response.............................................................................................................11
  2.4 Servlet (avanzado)...................................................................................................................15
  2.5 JSP (Avanzado)........................................................................................................................17
  2.6 JSTL........................................................................................................................................19
3 Frameworks: Struts, JSF y Spring.............................................................................................21
  3.1 Patrón MVC.............................................................................................................................21
  3.2 Struts........................................................................................................................................22
  3.3 JSF...........................................................................................................................................24
  3.4 Spring......................................................................................................................................26
4 AJAX..............................................................................................................................................28
  4.1 Introducción.............................................................................................................................28
  4.2 Principales elementos de AJAX..............................................................................................28
  4.3 Ejemplo de uso de AJAX........................................................................................................30
  4.4 Otras posibilidades..................................................................................................................34
5 ANEXO..........................................................................................................................................35
  5.1 INSTALACIÓN DE TOMCAT...............................................................................................35
  5.2 INTEGRACIÓN DE TOMCAT Y ECLIPSE..........................................................................42
  5.3 IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS.....................46




6 de febrero de 2008                                                 Tema 4                                                                          3
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 (http://jakarta.apache.org/tomcat/index.html) que será el que utilizaremos en este
       curso,
   •     Caucho Resin (http://www.caucho.com/) y
   •     Jetty (http://jetty.mortbay.org/index.html).
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.


6 de febrero de 2008                          Tema 4                                             4
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-INFclasses: en este directorio se encuentran las clases de apoyo
                       (ficheros *.class).
              WEB-INFlib: 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.




6 de febrero de 2008                           Tema 4                                                5
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 de febrero de 2008                           Tema 4                                               6
Compilar los ficheros fuentes (Servlets y clases de apoyo). Los ficheros compilados (*.class) deben
residir en el directorio WEB-INFclasses. 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:

       http://servidor:puerto/contexto/componenteWeb?query_string




   1.4 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"
"http://java.sun.com/dtd/web-app_2_3.dtd">
       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
        http://servidor:puerto/contexto/servlet/HolaServlet:
         <servlet>

6 de febrero de 2008                          Tema 4                                             7
<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>




6 de febrero de 2008                          Tema 4                                              8
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();
       }
}

6 de febrero de 2008                           Tema 4                                               9
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
(http://localhost:8080/examples/servlets/index.html).

   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,

6 de febrero de 2008                          Tema 4                                             10
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):




6 de febrero de 2008                           Tema 4                                              11
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).




6 de febrero de 2008                        Tema 4                                            12
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


6 de febrero de 2008                           Tema 4                                              13
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                                            RESPONSE
La petición es la información que envía un           La respuesta es la información que envía el
cliente a un servidor, esta información incluye      servidor al cliente. Se debe indicar que tipo de
quién ha realizado la petición (dirección ip, tipo   información se está devolviendo, si es texto
navegador, etc) y la información propiamente         (html, plain) o binario (imagen). Además, se
introducida por el usuario en el formulario.         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


6 de febrero de 2008                            Tema 4                                             14
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:




6 de febrero de 2008                          Tema 4                                           15
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.


6 de febrero de 2008                           Tema 4                                              16
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.




6 de febrero de 2008                           Tema 4                                              17
¡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

6 de febrero de 2008                          Tema 4                                             18
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.
<%                                                <jsp:useBean id="cart"
ShoppingCart carrito =                            class="cart.ShoppingCart" scope="session"/>
(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);
}
%>




   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


6 de febrero de 2008                          Tema 4                                              19
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)          Soporte de variables, control de flujo y gestión de URL.
XML (prefijo: x)           Control de flujo, transformaciones.
Internationalization       Formateo de mensajes, números y fechas.
(prefijo: fmt)
Database (prefijo: sql)    Realización de consultas y actualizaciones SQL.
Functions (prefijo: fn)    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                                           <%@ taglib prefix="c"
import="com.cursojava.model.Cliente,               uri="http://java.sun.com/jstl/core" %>
java.util.*"%>                                     <p><h1>Listado de clientes</h1></p>
<p><h1>Listado de clientes</h1></p>                <c:forEach items="${agenda}" var="cliente">
<%                                                 <c:choose>
List agenda =                                      <c:when test="${not empty cliente.nombre}" >
(List)request.getAttribute("agenda");              <c:out value="${cliente.nombre}"/><br/>
Iterator agendaIter = agenda.iterator();           </c:when>
while(agendaIter.hasNext()) {                      <c:otherwise>
Cliente cliente = (Cliente)agendaIter.next();      INDEFINIDO<br/>
if( (cliente!=null ) &&                            </c:otherwise>
(cliente.getLastName()!=null) &&                   </c:choose><br/>
(cliente.getNombre().length() > 0)) {              </c:forEach><br/>
%>                                                 <jsp:useBean id="now" class="java.util.Date" />
<%=cliente.getNombre()%><br/>                      <p><h5>Last Updated on: <c:out
<%                                                 value="${now}"/></h5></p>
}
else {
%>
INDEFINIDO<br/>
<%
}
}
%>
<p><h5>Última actualización: <%=new
Date()%></h5></p>




6 de febrero de 2008                            Tema 4                                          20
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       - Define los datos y la lógica de negocio de la aplicación.
de lógica de       - En esta capa se llevan a cabo las consultas a BD, los procesos del negocio y
negocio            las ordenes de procesamiento.
                   - Nos encontraremos con los datos y el comportamiento que sea independiente
                   de la presentación
VIEW o capa de     - Muestra la información según el tipo de cliente (HTML, XML, etc).
presentación       - 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)

6 de febrero de 2008                        Tema 4                                              21
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 (http://st-
www.cs.uiuc.edu/users/smarch/st-docs/mvc.html).



   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 (http://struts.apache.org/1.3.8/).
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:




6 de febrero de 2008                           Tema 4                                               22
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 email 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. (struts-
        config.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.

6 de febrero de 2008                           Tema 4                                               23
   <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 struts-
config.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

6 de febrero de 2008                           Tema 4                                              24
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.

6 de febrero de 2008                           Tema 4                                             25
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.




6 de febrero de 2008                           Tema 4                                              26
6 de febrero de 2008   Tema 4   27
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();



6 de febrero de 2008                           Tema 4                                              28
} 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

6 de febrero de 2008                          Tema 4                                                29
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-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<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;
 }


6 de febrero de 2008                          Tema 4                                             30
}
}
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)


6 de febrero de 2008                          Tema 4                                               31
* @see javax.servlet.http.HttpServlet#HttpServlet()
*/
public MiServlet() {
super();
}

/* (non-Java-doc)
* @see 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="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-
app_2_4.xsd">

<display-name>aplicacion ajax</display-name>
<servlet>

<description></description>
<display-name>MiServlet</display-name>
<servlet-name>MiServlet</servlet-name>


6 de febrero de 2008                           Tema 4                                               32
<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
http://localhost:8080/cursoAJAX/index.jsp 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".




6 de febrero de 2008                            Tema 4                                             33
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
http://www.w3schools.com/ajax/default.asp.

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 (http://ajaxanywhere.sourceforge.net)

- DWR (http://getahead.org/dwr/)

Y, por si no tenéis suficiente, aquí tenéis una página con un listado muy amplio
http://ajaxpatterns.org/Java_Ajax_Frameworks




6 de febrero de 2008                        Tema 4                                           34
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 http://tomcat.apache.org. 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):




6 de febrero de 2008                          Tema 4                                             35
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.




6 de febrero de 2008                           Tema 4                                              36
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.




6 de febrero de 2008                         Tema 4                                            37
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.




6 de febrero de 2008                         Tema 4                                             38
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
http://localhost:8080 con nuestro navegador (IE, Mozilla, etc).




6 de febrero de 2008                       Tema 4                                          39
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

6 de febrero de 2008                         Tema 4                                             40
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 http://localhost:8080 con nuestro navegador (IE, Mozilla, etc).




6 de febrero de 2008                         Tema 4                                            41
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:




6 de febrero de 2008                         Tema 4                                            42
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:



6 de febrero de 2008                        Tema 4                                         43
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:

6 de febrero de 2008                         Tema 4                                             44
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):




6 de febrero de 2008                         Tema 4                                            45
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’:




6 de febrero de 2008                         Tema 4                                             46
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:




6 de febrero de 2008                           Tema 4                                               47
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

6 de febrero de 2008                          Tema 4                                             48
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:




6 de febrero de 2008                          Tema 4                                              49
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):

6 de febrero de 2008                         Tema 4                                              50
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):




6 de febrero de 2008                         Tema 4                                               51
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í.


6 de febrero de 2008                          Tema 4                                             52
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’.




6 de febrero de 2008                          Tema 4                                             53

Weitere ähnliche Inhalte

Was ist angesagt? (9)

Manual instalacion oracle 11g xe esp
Manual instalacion oracle 11g xe espManual instalacion oracle 11g xe esp
Manual instalacion oracle 11g xe esp
 
Unidad 06
Unidad 06Unidad 06
Unidad 06
 
Wordpress, características y guía de uso1
Wordpress, características y guía de uso1Wordpress, características y guía de uso1
Wordpress, características y guía de uso1
 
A6 instalación de media wiki
A6   instalación de media wikiA6   instalación de media wiki
A6 instalación de media wiki
 
UDA-Migracion a v2
UDA-Migracion a v2UDA-Migracion a v2
UDA-Migracion a v2
 
Webutil
WebutilWebutil
Webutil
 
Integración de joomla en redes sociales
Integración de joomla en redes socialesIntegración de joomla en redes sociales
Integración de joomla en redes sociales
 
Manual Wordpress
Manual WordpressManual Wordpress
Manual Wordpress
 
Manual Admon Contenidos Joomla 1.5 V2 Gen
Manual Admon Contenidos Joomla 1.5 V2 GenManual Admon Contenidos Joomla 1.5 V2 Gen
Manual Admon Contenidos Joomla 1.5 V2 Gen
 

Ähnlich wie Tema 4 (20)

Tema 5
Tema 5Tema 5
Tema 5
 
Tema 6
Tema 6Tema 6
Tema 6
 
Tema 3
Tema 3Tema 3
Tema 3
 
Video
VideoVideo
Video
 
Spring mvc
Spring mvcSpring mvc
Spring mvc
 
Tema 6
Tema 6Tema 6
Tema 6
 
Sesion03 apuntes
Sesion03 apuntesSesion03 apuntes
Sesion03 apuntes
 
Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)
 
Deploy
DeployDeploy
Deploy
 
Java
JavaJava
Java
 
Introducción a Tomcat
Introducción a TomcatIntroducción a Tomcat
Introducción a Tomcat
 
Resumen jee
Resumen jeeResumen jee
Resumen jee
 
[ES] Introducción a las Aplicaciones Web con Java
[ES] Introducción a las Aplicaciones Web con Java[ES] Introducción a las Aplicaciones Web con Java
[ES] Introducción a las Aplicaciones Web con Java
 
La Arquitectura De Netbeans V2
La Arquitectura De Netbeans V2La Arquitectura De Netbeans V2
La Arquitectura De Netbeans V2
 
Spring mvc
Spring mvcSpring mvc
Spring mvc
 
Prueba1.pdf
Prueba1.pdfPrueba1.pdf
Prueba1.pdf
 
20001215 Programación de Servlets y WML
20001215   Programación de Servlets y WML20001215   Programación de Servlets y WML
20001215 Programación de Servlets y WML
 
Aplicaciones web con jakarta struts - Javier Oliver Fulguera
Aplicaciones web con jakarta struts  - Javier Oliver FulgueraAplicaciones web con jakarta struts  - Javier Oliver Fulguera
Aplicaciones web con jakarta struts - Javier Oliver Fulguera
 
1/9 Curso JEE5, Soa, Web Services, ESB y XML
1/9 Curso JEE5, Soa, Web Services, ESB y XML1/9 Curso JEE5, Soa, Web Services, ESB y XML
1/9 Curso JEE5, Soa, Web Services, ESB y XML
 
Introducción al desarrollo de aplicaciones web en Java
Introducción al desarrollo de aplicaciones web en JavaIntroducción al desarrollo de aplicaciones web en Java
Introducción al desarrollo de aplicaciones web en Java
 

Mehr von Julio Pari

Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Julio Pari
 
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesLinks kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
 
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesComandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
 
Indice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCIndice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCJulio Pari
 
Arquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMArquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMJulio Pari
 
Jelastic Enterprise
Jelastic EnterpriseJelastic Enterprise
Jelastic EnterpriseJulio Pari
 
Marketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor OsorioMarketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor OsorioJulio Pari
 
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor CorderoIngenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor CorderoJulio Pari
 
Documento de Arquitectura
Documento de ArquitecturaDocumento de Arquitectura
Documento de ArquitecturaJulio Pari
 
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISISolucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISIJulio Pari
 
Práctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa IIPráctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa IIJulio Pari
 
Armas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilasArmas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilasJulio Pari
 
Formato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISIFormato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISIJulio Pari
 
Cuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hijaCuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hijaJulio Pari
 
Ingeniería de Software Examen Parcial
Ingeniería de Software Examen ParcialIngeniería de Software Examen Parcial
Ingeniería de Software Examen ParcialJulio Pari
 
Sistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen ParcialSistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen ParcialJulio Pari
 
Php07 consultas bd
Php07 consultas bdPhp07 consultas bd
Php07 consultas bdJulio Pari
 
Php06 instalacion my_sql
Php06 instalacion my_sqlPhp06 instalacion my_sql
Php06 instalacion my_sqlJulio Pari
 
Php05 funciones usuario
Php05 funciones usuarioPhp05 funciones usuario
Php05 funciones usuarioJulio Pari
 

Mehr von Julio Pari (20)

Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
 
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesLinks kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
 
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesComandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
 
Indice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCIndice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPC
 
Arquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMArquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSM
 
Jelastic Enterprise
Jelastic EnterpriseJelastic Enterprise
Jelastic Enterprise
 
Marketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor OsorioMarketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor Osorio
 
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor CorderoIngenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
 
Documento de Arquitectura
Documento de ArquitecturaDocumento de Arquitectura
Documento de Arquitectura
 
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISISolucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
 
Práctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa IIPráctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa II
 
Armas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilasArmas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilas
 
UML Java
UML JavaUML Java
UML Java
 
Formato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISIFormato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISI
 
Cuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hijaCuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hija
 
Ingeniería de Software Examen Parcial
Ingeniería de Software Examen ParcialIngeniería de Software Examen Parcial
Ingeniería de Software Examen Parcial
 
Sistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen ParcialSistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen Parcial
 
Php07 consultas bd
Php07 consultas bdPhp07 consultas bd
Php07 consultas bd
 
Php06 instalacion my_sql
Php06 instalacion my_sqlPhp06 instalacion my_sql
Php06 instalacion my_sql
 
Php05 funciones usuario
Php05 funciones usuarioPhp05 funciones usuario
Php05 funciones usuario
 

Tema 4

  • 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 07-02-2008 11: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: 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 uso 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: http://creativecommons.org/licenses/by-sa/2.5/es/legalcode.es 6 de febrero de 2008 Tema 4 2
  • 3. UNIDAD IV. DESARROLLO WEB CON LAS TECNOLOGÍAS J2EE 0 Licencia............................................................................................................................................2 1 Estructura de una aplicación Web................................................................................................4 1.1 Componentes y contenedores Web............................................................................................4 1.2 Elementos de una aplicación web..............................................................................................5 1.3 Desarrollo y despliegue de una aplicación web........................................................................6 1.4 El fichero descriptor: Web.xml..................................................................................................7 2 Servlet y JSP...................................................................................................................................9 2.1 Servlet (básico)..........................................................................................................................9 2.2 JSP (Básico).............................................................................................................................10 2.3 Request and Response.............................................................................................................11 2.4 Servlet (avanzado)...................................................................................................................15 2.5 JSP (Avanzado)........................................................................................................................17 2.6 JSTL........................................................................................................................................19 3 Frameworks: Struts, JSF y Spring.............................................................................................21 3.1 Patrón MVC.............................................................................................................................21 3.2 Struts........................................................................................................................................22 3.3 JSF...........................................................................................................................................24 3.4 Spring......................................................................................................................................26 4 AJAX..............................................................................................................................................28 4.1 Introducción.............................................................................................................................28 4.2 Principales elementos de AJAX..............................................................................................28 4.3 Ejemplo de uso de AJAX........................................................................................................30 4.4 Otras posibilidades..................................................................................................................34 5 ANEXO..........................................................................................................................................35 5.1 INSTALACIÓN DE TOMCAT...............................................................................................35 5.2 INTEGRACIÓN DE TOMCAT Y ECLIPSE..........................................................................42 5.3 IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS.....................46 6 de febrero de 2008 Tema 4 3
  • 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 (http://jakarta.apache.org/tomcat/index.html) que será el que utilizaremos en este curso, • Caucho Resin (http://www.caucho.com/) y • Jetty (http://jetty.mortbay.org/index.html). 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. 6 de febrero de 2008 Tema 4 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-INFclasses: en este directorio se encuentran las clases de apoyo (ficheros *.class).  WEB-INFlib: 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. 6 de febrero de 2008 Tema 4 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 de febrero de 2008 Tema 4 6
  • 7. Compilar los ficheros fuentes (Servlets y clases de apoyo). Los ficheros compilados (*.class) deben residir en el directorio WEB-INFclasses. 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: http://servidor:puerto/contexto/componenteWeb?query_string 1.4 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" "http://java.sun.com/dtd/web-app_2_3.dtd">  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 http://servidor:puerto/contexto/servlet/HolaServlet: <servlet> 6 de febrero de 2008 Tema 4 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> 6 de febrero de 2008 Tema 4 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(); } } 6 de febrero de 2008 Tema 4 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 (http://localhost:8080/examples/servlets/index.html). 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, 6 de febrero de 2008 Tema 4 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): 6 de febrero de 2008 Tema 4 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). 6 de febrero de 2008 Tema 4 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 6 de febrero de 2008 Tema 4 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 RESPONSE La petición es la información que envía un La respuesta es la información que envía el cliente a un servidor, esta información incluye servidor al cliente. Se debe indicar que tipo de quién ha realizado la petición (dirección ip, tipo información se está devolviendo, si es texto navegador, etc) y la información propiamente (html, plain) o binario (imagen). Además, se introducida por el usuario en el formulario. 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 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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 6 de febrero de 2008 Tema 4 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. <% <jsp:useBean id="cart" ShoppingCart carrito = class="cart.ShoppingCart" scope="session"/> (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); } %> 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 6 de febrero de 2008 Tema 4 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) Soporte de variables, control de flujo y gestión de URL. XML (prefijo: x) Control de flujo, transformaciones. Internationalization Formateo de mensajes, números y fechas. (prefijo: fmt) Database (prefijo: sql) Realización de consultas y actualizaciones SQL. Functions (prefijo: fn) 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 <%@ taglib prefix="c" import="com.cursojava.model.Cliente, uri="http://java.sun.com/jstl/core" %> java.util.*"%> <p><h1>Listado de clientes</h1></p> <p><h1>Listado de clientes</h1></p> <c:forEach items="${agenda}" var="cliente"> <% <c:choose> List agenda = <c:when test="${not empty cliente.nombre}" > (List)request.getAttribute("agenda"); <c:out value="${cliente.nombre}"/><br/> Iterator agendaIter = agenda.iterator(); </c:when> while(agendaIter.hasNext()) { <c:otherwise> Cliente cliente = (Cliente)agendaIter.next(); INDEFINIDO<br/> if( (cliente!=null ) && </c:otherwise> (cliente.getLastName()!=null) && </c:choose><br/> (cliente.getNombre().length() > 0)) { </c:forEach><br/> %> <jsp:useBean id="now" class="java.util.Date" /> <%=cliente.getNombre()%><br/> <p><h5>Last Updated on: <c:out <% value="${now}"/></h5></p> } else { %> INDEFINIDO<br/> <% } } %> <p><h5>Última actualización: <%=new Date()%></h5></p> 6 de febrero de 2008 Tema 4 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 - Define los datos y la lógica de negocio de la aplicación. de lógica de - En esta capa se llevan a cabo las consultas a BD, los procesos del negocio y negocio las ordenes de procesamiento. - Nos encontraremos con los datos y el comportamiento que sea independiente de la presentación VIEW o capa de - Muestra la información según el tipo de cliente (HTML, XML, etc). presentación - 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) 6 de febrero de 2008 Tema 4 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 (http://st- www.cs.uiuc.edu/users/smarch/st-docs/mvc.html). 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 (http://struts.apache.org/1.3.8/). 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: 6 de febrero de 2008 Tema 4 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 email 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. (struts- config.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. 6 de febrero de 2008 Tema 4 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 struts- config.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 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 26
  • 27. 6 de febrero de 2008 Tema 4 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(); 6 de febrero de 2008 Tema 4 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 6 de febrero de 2008 Tema 4 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-8859-1" pageEncoding="ISO-8859-1"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <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; } 6 de febrero de 2008 Tema 4 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) 6 de febrero de 2008 Tema 4 31
  • 32. * @see javax.servlet.http.HttpServlet#HttpServlet() */ public MiServlet() { super(); } /* (non-Java-doc) * @see 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="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web- app_2_4.xsd"> <display-name>aplicacion ajax</display-name> <servlet> <description></description> <display-name>MiServlet</display-name> <servlet-name>MiServlet</servlet-name> 6 de febrero de 2008 Tema 4 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 http://localhost:8080/cursoAJAX/index.jsp 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". 6 de febrero de 2008 Tema 4 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 http://www.w3schools.com/ajax/default.asp. 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 (http://ajaxanywhere.sourceforge.net) - DWR (http://getahead.org/dwr/) Y, por si no tenéis suficiente, aquí tenéis una página con un listado muy amplio http://ajaxpatterns.org/Java_Ajax_Frameworks 6 de febrero de 2008 Tema 4 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 http://tomcat.apache.org. 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): 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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. 6 de febrero de 2008 Tema 4 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 http://localhost:8080 con nuestro navegador (IE, Mozilla, etc). 6 de febrero de 2008 Tema 4 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 6 de febrero de 2008 Tema 4 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 http://localhost:8080 con nuestro navegador (IE, Mozilla, etc). 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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): 6 de febrero de 2008 Tema 4 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’: 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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 6 de febrero de 2008 Tema 4 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: 6 de febrero de 2008 Tema 4 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): 6 de febrero de 2008 Tema 4 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): 6 de febrero de 2008 Tema 4 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í. 6 de febrero de 2008 Tema 4 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’. 6 de febrero de 2008 Tema 4 53