Estructura de directorios para una aplicacin JSF

Una aplicacin JSF se corresponde con una estructura de directorios que sigue un
modelo estndar, la cual se puede comprimir en un archivo con extensin WAR, para
mayor
comodidad y portabilidad. Esta estructura de directorios estndar es:
Aplicacin/
Ficheros HTML y JSP
WEB-INF/
archivos de configuracin
classes/
archivos .class
lib/
libreras

Con lo que la estructura del archivo WAR, queda tal que as:

donde el directorio META-INF se genera automticamente al crear el archivo .war.

Modelo Vista Controlador en JSF
Introduccin
El patrn MVC (Modelo Vista Controlador), ver Figura 3.1, nos permite
separar la lgica de control (qu cosas hay que hacer pero no cmo), la
lgica de negocio (cmo se hacen las cosas) y la lgica de presentacin
(cmo interaccionar con el usuario).
Utilizando este tipo de patrn es posible conseguir ms calidad, un
mantenimiento ms fcil, perder el miedo al folio en blanco (existe un

patrn de partida por el que empezar un proyecto), etc. al margen de todo

esto, una de las cosas ms importantes que permite el uso de este patrn
consiste en normalizar y estandarizar el desarrollo de Software.

Modelo
Todas las aplicaciones software dejan a los usuarios manipular ciertos datos que
proceden de una realidad sobre la que se pretende actuar, como supermercados,
itinerarios de viaje, o cualquier dato requerido en un dominio problemtico particular. A
estos datos en estado puro, que representan el estado de la realidad se les llama modelo:
modelan la parte de la realidad sobre la que se desea actuar.
El modelo, pues, es el objeto que representa y trabaja directamente con los datos del
programa: gestiona los datos y controla todas sus transformaciones. El modelo no tiene
conocimiento especfico de los diferentes controladores y/o vistas, ni siquiera contiene
referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de
mantener enlaces entre el modelo y sus vistas, y notificar a las vistas cundo deben
reflejar un cambio en el modelo.
En nuestro ejemplo bsico, lo primero que hay que hacer es definir el modelo, que se ve
reflejado en el fichero UsuarioBean.java, donde se aprecia la clase UsuarioBean, que
contiene los elementos necesarios para manejar los datos de la aplicacin: es necesario
un campo que almacene el nombre del usuario que entr, y otro para su correspondiente
contrasea, junto con sus respectivos mtodos de asignacin y recuperacin:
public class UsuarioBean {
private String nombre;
private String password;
// ATRIBUTO: nombre
public String getNombre() { return nombre; }
public void setNombre(String nuevoValor) { nombre = nuevoValor; }
// ATRIBUTO: password
public String getPassword() { return password; }
public void setPassword(String nuevoValor) { password = nuevoValor; }
}

Este modelo a utilizar en la aplicacin se le comunica al sistema JSF mediante el fichero

faces-config.xml, donde se detalla la parte de managed-bean, donde se aprecia un
bean denominado usuario, que est recogido en la clase UsuarioBean, y con un mbito
de sesin:
<managed-bean>
<managed-bean-name>usuario</managed-bean-name>

<managed-bean-class>UsuarioBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

Vista
La vista es el objeto que maneja la presentacin visual de los datos gestionados por el
Modelo. Genera una representacin visual del modelo y muestra los datos al usuario.
Interacciona con el modelo a travs de una referencia al propio modelo.
En el ejemplo bsico, la vista est manipulada a travs de las pginas JSF, es decir,
mediante las pginas index.jsp y hola.jsp. JSF conecta la vista y el modelo. Como ya se
ha visto, un componente de la vista puede ligarse a un atributo de un bean del modelo,
como: <h:inputText value="#{usuario.nombre}"/> donde se ve como se declara un
campo de texto de entrada (inputText) en la vista, ese campo de texto recoge su valor de
entrada en el atributo nombre de un bean denominado usuario. De esta manera se
establece el vnculo de enlace en vista y modelo.

Controlador
El controlador es el objeto que proporciona significado a las rdenes del usuario,
actuando sobre los datos representados por el modelo. Entra en accin cuando se realiza
alguna operacin, ya sea un cambio en la informacin del modelo o una interaccin
sobre la Vista. Se comunica con el modelo y la vista a travs de una referencia al propio
modelo. Adems, JSF opera como un gestor que reacciona ante los eventos provocados
por el usuario, procesa sus acciones y los valores de estos eventos, y ejecuta cdigo para
actualizar el modelo o la vista.
Retomando el ejemplo bsico, una parte del controlador la recogen las lineas de
cdigo del fichero index.jsp que capturan los datos del nombre de usuario, su
contrasea, y el
botn de Aceptar:
<h:inputText value="#{usuario.nombre}"/>
<h:inputSecret value="#{usuario.password}"/>
<h:commandButton value="Aceptar" action="login"/>
y la parte del dichero hola.jsp que muestra el nombre por pantalla:
<h:outputText value="#{usuario.nombre}"/>
Por otro lado, est el control para las reglas de navegacin, contenido en el fichero
faces-config.xml, donde por ejemplo, se indica que estando index.jsp, si ocurre una
accin
denominada login, navegaremos a la pgina hola.jsp, esta accin comentada, es un
string que se declara en la vista como un atributo del botn de aceptar que aparece en el
formulario del ejemplo bsico. El fichero faces-config sera el siguiente:
<navigation-rule>
<from-view-id>/index.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/hola.jsp</to-view-id>
</navigation-case>
</navigation-rule>

y la parte de la vista que establece la accin que activa la navegacin es:

<h:commandButton value="Aceptar" action="login"/> Por ltimo,
termina de definirse el controlador de la aplicacin con el servlet faces, definido en el
fichero web.xml:
<web-app>
<servlet>

<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
</web-app>

Con la directiva <servlet> se establece el nico servlet de nuestra aplicacin es el propio

del framework JSF. La directiva <servlet-mapping> indica la ruta (url) para acceder a
servlet definido anteriormente. Cualquier pgina JSP que pretendamos visualizar, si
contiene la extensin .faces, se visualizar a traves de JSF.
Por ltimo con <welcome-file-list> se establece como pgina de arranque de la
aplicacin index.html. Posteriormente, esta pgina se redirecciona a index.faces, esto
se hace as para que el framework JSF, a travs de su servlet principal tome el control.
Si no se hiciera de esta manera, el servidor de aplicaciones mostrara una simple pgina
JSP como tal, y la compilacin de dicha pgina, fuera del marco JSF, provocara errores.

Ciclo de vida de una pgina JavaServer Faces

El ciclo de vida de una pgina JavaServer Faces page es similar al de una pgina JSP:
El cliente hace una peticin HTTP (Hiper Text Transfer Protocol) de la pgina y el
servidor responde con la pgina traducida a HTML. Sin embargo, debido a las
caractersticas extras que ofrece la tecnologa JavaServer Faces, el ciclo de vida
proporciona algunos servicios adicionales mediante la ejecucin de algunos pasos
extras.
Los pasos del ciclo de vida se ejecutan dependiendo de si la peticin se origin o no
desde una aplicacin JavaServer Faces y si la respuesta es o no generada con la fase de
renderizado del ciclo de vida de JavaServer Faces. Esta seccin explica los diferentes
escenarios del ciclo de vida.
Escenarios de Procesamiento del Ciclo de Vida de una Peticin
Una aplicacin JavaServer Faces soporta dos tipos diferentes de respuestas y dos tipos
diferentes de peticiones; la idea es que en una aplicacin JSF se pueden mezclar pginas
JSF y JSP (no-JSF) y, segn se pidan y/o se devuelvan una u otras, tendremos diferentes
respuestas y/o peticiones:
Respuesta Faces: Una respuesta servlet que se gener mediante la ejecucin de la fase
Renderizar la Respuesta del ciclo de vida de procesamiento de la respuesta.
Respuesta No-Faces: Una respuesta generada por el servlet en la que no se ha
ejecutado la fase Renderizar la Respuesta. Un ejemplo es una pgina JSP que no
incorpora componentes JavaServer Faces.
Peticin Faces: Una peticin al servlet que fue enviada desde una Respuesta Faces
previamente generada. Un ejemplo es un formulario enviado desde un componente de
interfaz de usuario JavaServer Faces, donde la URI de la peticin identifica el rbol de
componentes JavaServer Faces para usar el procesamiento de peticin.
Peticin No-Faces: Una peticin al servlet que fue enviada a un componente de
aplicacin como un servlet o una pgina JSP, en vez de directamente a un componente
JavaServer Faces.
La combinacin de estas peticiones y respuestas resulta en tres posibles escenarios del
ciclo de vida que pueden existir en una aplicacin JavaServer Faces:

Escenario 1: Una peticin No-Faces genera una respuesta Faces: Un ejemplo de este
escenario es cuando se pulsa un enlace de una pgina HTML que abre una pgina que
contiene componentes JavaServer Faces. Para construir una respuesta Faces desde una
peticin No-Faces, una aplicacin debe proporcionar un mapeo FacesServlet en la URL
de la pgina que contiene componentes JavaServer Faces. FacesServlet acepta
peticiones entrantes y pasa a la implementacin del ciclo de vida para su procesamiento.
Escenario 2: Una peticin Faces genera una respuesta no-Faces: Algunas veces una
aplicacin JavaServer Faces podra necesitar redirigir la salida a un recurso diferente de
la aplicacin Web (p.ej. una imagen sencilla) o generar una respuesta que no contiene
componentes JavaServer Faces. En estas situaciones, el desarrollador debe saltarse la
fase de renderizado (renderizar la respuesta) llamando a
FacesContext.responseComplete. FacesContext contiene toda la informacin
asociada con una peticin Faces particular. Este mtodo se puede invocar durante las
fases aplicar valores de respuesta, procesar validaciones o actualizar los valores del
modelo.
Escenario 3: Una peticin Faces genera una respuesta Faces:
Es el escenario ms comn en el ciclo de vida de una aplicacin JavaServer Faces.
Este escenario implica componentes JavaServer Faces enviando una peticin a una
aplicacin JavaServer Faces utilizando el FacesServlet. Como la peticin ha sido
manejada por la implementacin JavaServer Faces, la aplicacin no necesita pasos
adicionales para generar la respuesta. Todos los oyentes, validadores y conversores
sern invocados automticamente durante la fase apropiada del ciclo de vida estndar,
como se describe en la siguiente seccin.
Ciclo de Vida Estndar de Procesamiento de Peticiones
La mayora de los usuarios de la tecnologa JavaServer Faces no necesitarn conocer a
fondo el ciclo de vida de procesamiento de una peticin. Sin embargo, conociendo lo
que la tecnologa JavaServer Faces realiza para procesar una pgina, un desarrollador de
aplicaciones JavaServer Faces no necesitar preocuparse de los problemas de
renderizado asociados con otras tecnologas UI. Un ejemplo sera el cambio de estado
de los componentes individuales: si la seleccin de un componente, como por ejemplo
una casilla de verificacin (checkbox ) afecta a la apariencia de otro componente de la
pgina, la tecnologa JavaServer Faces manejar este evento de la forma apropiada y no
permitir que se dibuje la pgina sin reflejar este cambio.
La figura 3.2 ilustra los pasos del ciclo de vida peticin-respuesta JavaServer Faces.

Reconstituir el rbol de componentes

Cuando se hace una peticin de una pgina JavaServer Faces, o cuando se produce un
evento como pulsar sobre un enlace o un botn, el sistema JavaServer Faces entra en el
estado reconstituir el rbol de componentes.
Durante esta fase, la implementacin JavaServer Faces construye el rbol de
componentes de la pgina JavaServer Faces, conecta los manejadores de eventos y los
validadores y graba el estado en el FacesContext.
Aplicar valores de la peticin
Una vez construido el rbol de componentes, cada componente del rbol extrae su
nuevo valor desde los parmetros de la peticin con su mtodo decode. A continuacin,
el valor se almacena localmente en el componente. Si la conversin del valor falla , se
genera un mensaje de error asociado con el componente y se pone en la cola de
FacesContext. Este mensaje se mostrar durante la fase renderizar la respuesta, junto
con cualquier error de validacin resultante de la fase procesar validaciones.
Si durante esta fase se produce algn evento, la implementacin JavaServer Faces
comunica estos eventos a los oyentes interesados.
En este punto, si la aplicacin necesita redirigirse a un recurso de aplicacin Web
diferente o generar una respuesta que no contenga componentes JavaServer Faces,
puede llamar a FacesContext.responseComplete.
En este momento, se han puesto los nuevos valores en los componentes y los mensajes
y eventos se han puesto en sus colas.
Procesar validaciones
Durante esta fase, el sistema JavaServer Faces procesa todas las validaciones registradas
con los componentes del rbol. Examina los atributos del componente especificados por
las reglas de validacin y evala las reglas con los valores de dichos atributos. Si un
valor incumple una regla, la implementacin JavaServer Faces aade un mensaje de
error al FacesContext y el ciclo de vida avanza directamente hasta la fase renderizar las
respuesta para que la pgina sea dibujada de nuevo incluyendo los mensajes de error. Si

haba errores de conversin de la fase aplicar los valores a la peticin, tambin se

mostrarn.
Actualizar los valores del modelo
Una vez que la implementacin JavaServer Faces determina que el dato es vlido, puede
pasar por el rbol de componentes y actualizar los valores del modelo con los nuevos
valores pasados en la peticin. Slo se actualizarn los componentes que tengan
expresiones valueRef. Si el dato local no se puede convertir a los tipos especificados
por los atributos del objeto del modelo, el ciclo de vida avanza directamente a la fase
renderizar las respuesta, durante la que se dibujar de nuevo la pgina mostrando los
errores, similar a lo que sucede con los errores de validacin.
Invocar Aplicacin
Durante esta fase, la implementacin JavaServer Faces maneja cualquier evento a nivel
de aplicacin, como enviar un formulario o enlazar a otra pgina.
En este momento, si la aplicacin necesita redirigirse a un recurso de aplicacin web
diferente o generar una respuesta que no contenga componentes JavaServer Faces,
puede llamar a FacesContext.responseComplete. Posteriormente, la implementacin
JavaServer Faces configura el rbol de componentes de la respuesta a esa nueva pgina
y, por ltimo, transfiere el control a la fase Renderizar la Respuesta.
Renderizar la Respuesta
Durante esta fase, la implementacin JavaServer Faces invoca los atributos de
codificacin de los componentes y dibuja los componentes del rbol de componentes
grabado en el FacesContext.
Si se encontraron errores durante las fases aplicar los valores a la peticin, procesar
validaciones o actualizar los valores del modelo, se dibujar la pgina original. Si las
pginas contienen etiquetas output_errors, cualquier mensaje de error que haya en la
cola se mostrar en la pgina.
Se pueden aadir nuevos componentes en el rbol si la aplicacin incluye
renderizadores personalizados, que definen cmo renderizar un componente. Despus
de que se haya renderizado el contenido del rbol, ste se graba para que las siguientes
peticiones puedan acceder a l y est disponible para la fase reconstituir el rbol de
componentes de las siguientes llamadas.