Programación IV

Programación IV
Clase Teórica Nº 5
Fundamentos del framework JavaServer Faces (JSF).

Objetivos

Al final de la clase los estudiantes serán capaces de:

 Comprender en qué consiste el framework “JavaServer Faces”, los servicios que éste proporciona y
principales componentes.
 Comprender en qué consisten los JavaBeans administrados y entender su alcance.
 Entender cómo se comunican las vistas con la lógica de la aplicación.
 Comprender los elementos básicos de la interfaz de usuario en JSF.
 Saber navegar desde una página Web hacia un Bean y desde una clase Java hacia una página Web.

Introducción

-JavaServer Faces (JSF) es otro entorno de desarrollo de aplicaciones Web en Java, diferente al de los Servlets
que hemos visto hasta ahora. Es un entorno de trabajo (integrado en NetBeans) para desarrollar aplicaciones web
Java del lado del servidor.
Esta tecnología está diseñada para simplificar el desarrollo Web con Java, y fomenta la separación de la
presentación de las interfaces de usuario con la lógica de la aplicación.
JSF utilizaba JSPs, añadiendo librerías que contienen componentes de alto nivel (menús, paneles, campos de
texto, etc.), cada uno de estos componentes puede interactuar con el servidor de forma independiente. En la
actualidad, se utilizan “Facelets” que son páginas con extensión xhtml que sirven para lo mismo que las JSF pero
son una forma más sencilla de trabajar.
Como JavaServer Faces es un “framework”, simplifica el diseño de la estructura de la aplicación y también
proporciona librerías que hacen más fácil el desarrollo de la aplicación.
Con JavaServer Faces es posible utilizar Ajax (Asynchronous JavaScript and XML). Ajax es un enfoque en el
que las diferentes acciones que solicita el usuario se realizan dentro de una misma página, de tal manera que el
servidor no genera una nueva página sino sólo los datos.
En las aplicaciones tradicionales, cada petición al servidor hace que éste genere una nueva página
HTML/XHTML.
Las aplicaciones RIA (Rich Internet Applications), como lo es JSF, intentan simular las aplicaciones de
escritorio y, cuando usan Ajax, son más rápidas que las aplicaciones tradicionales.

Desarrollo

¿Qué es JavaServer Faces (JSF)?

Es el marco de aplicaciones web estándar para Java Enterprise Edition (JEE).

Es una tecnología que fue diseñada para simplificar la interfaz de usuario para aplicaciones web Java.
Uno de los puntos clave, fue el apoyo de las herramientas creadas para este tipo de aplicaciones.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 13
Programación IV

Por ser un estándar de Java, la tecnología cuenta con el apoyo de una industria muy sólida.
Esta tecnología ha crecido mucho en su uso a nivel mundial. Cuenta con un fuerte apoyo de IDEs de Java
(NetBeans, Eclipse, IntelliJ IDEA y otros), así como de servidores de aplicaciones con el objetivo de soportar y
desplegar las aplicaciones creadas con este framework.
La tecnología JSF incluye:
 Una interfaz de programación (API) que permite manipular los componentes típicos de una interfaz
gráfica (formularios, cajas de texto, botones, listas, tablas, objetos de acceso a datos, etc.), permite
manipular eventos, proporciona validación y conversión de datos en el lado del servidor y navegación
entre páginas, además de otras características.
 Dos bibliotecas de etiquetas JSP personalizadas (etiquetas JSF) para proporcionar los componentes de la
interfaz gráfica y para conectar los componentes a objetos en el lado del servidor.

Características de JavaServer Faces.

 Implementa el patrón de diseño MVC, proporcionando un enfoque orientado a eventos.
 RAD: desarrollo rápido de aplicaciones para web debido al número de componentes listos para
utilizarse.
 Componentes de interfaz de usuario: JSF tiene una API para crear componentes HTML complejos,
incluyendo de manera embebida dentro del componente tecnologías tales como JavaScript, CSS y html
integrado. Esto permite crear componentes reutilizables.
 Render-Kits: los componentes pueden desplegarse no solamente en navegadores web, sino también en
dispositivos móviles u otros tipos de clientes.
 Extensibilidad: JSF es altamente extensible debido a su arquitectura, permite crear más fácilmente
nuevos componentes, por lo que existen frameworks que extienden a JSF, por ejemplo Ajax, Rich Faces.
 Internacionalización: Las vistas pueden mostrarse en distintos idiomas.
 Manejo de condiciones por default más inteligentes: esto aplica en casos de navegación simples, los
cuales ya no se requiere agregarlos en el archivo de configuración “faces-config”.
 Manejo de anotaciones para varias configuraciones: simplifica en gran medida agregar un ManagedBean
a nuestra aplicación, evitando con ello, la declaración en el archivo de configuración “faces-config”.
 Soporte nativo para Ajax: esta tecnología ya es parte del ciclo de vida de JSF, por lo que facilita el
procesamiento de peticiones asíncronas.
 Soporte por default para Facelets: la tecnología de los Facelets toma en cuenta el ciclo de vida de JSF, a
diferencia de los JSPs.

JSF contiene dos importantes componentes de software: las Tag Libraries y los Managed Beans.

Tag Libraries.
Los Facelets son páginas .xhtml con librerías adicionales llamadas Tag libraries. Las librerías de etiquetas (tag
libraries) son componentes especiales de software que encapsulan funcionalidad dinámica y compleja. Estas
librerías las construyen especialistas en ciertos servicios, como, por ejemplo: el acceso a la base de datos, o el
manejo de botones, menús, desplegado de listas, etc. La idea principal es que el diseñador de las vistas pueda
incorporar poderoso contenido dinámico en sus páginas sin necesidad de saber cómo se codifican los detalles.
JSTL (JavaServer pages Standard Tag Library) es una librería que contiene la funcionalidad más común de
las aplicaciones Web. Los diseñadores de páginas Web sólo deben saber cómo incluir los tags. JSF proporciona
componentes para construir una aplicación con GUIs (Graphical User Interfaces: Interfaces de Usuario

______________________________________________________________________________________________________________
Ciclo 02 – 2023 14
Programación IV

Gráficas). El desarrollador personaliza objetos como menús, check box, botones, etc. manipulando los atributos
de los tags de cada uno de estos componentes.
Cuando creamos un proyecto en JavaServer Faces en NetBeans, se generan XHTML, las cual se llaman Facelets,
y ya tienen incluidas las Tag libraries.

JavaBeans Administrados (Managed Beans).

Un bean administrado (Managed Bean) es un JavaBean que puede ser accedido desde una página Web. El
Managed Bean se inventó para que el usuario remoto pueda comunicarse con un programa en Java que está en el
servidor. A diferencia de los JavaBeans, los Managed Beans no están obligados a implementar la interfaz
serializable.
En la figura siguiente se muestra la conexión de una página web con su Managed Bean asociado. JavaServer
Faces usa el mecanismo de los Managed Beans para establecer la conexión entre los datos que se despliegan al
usuario y lo que está registrado en el código Java.

Arquitectura JavaServer Faces.

Una aplicación JSF típica incluye los siguientes componentes:

______________________________________________________________________________________________________________
Ciclo 02 – 2023 15
Programación IV

Un conjunto de páginas JSP. JSF también admite otras tecnologías de presentación, por ejemplo,
Facelets.
Etiquetas personalizadas para representar objetos en las páginas.
Un conjunto de componentes JavaBeans (beans de apoyo) que definen las propiedades y funciones de
los componentes de la interfaz gráfica.
Objetos creados por el programador de la aplicación, como componentes personalizados, validadores,
convertidores o escuchadores de eventos.
Archivos de configuración para definir las reglas de navegación entre páginas, así como para configurar
beans y otros objetos.
Un descriptor de despliegue (archivo web.xml).

Patrón de diseño MVC con JavaServer Faces.

JSF implementa el patrón de diseño MVC con una amplia separación de responsabilidades.
El modelo contiene datos de la UI y es el responsable de almacenar los datos de la aplicación web. Se puede
implementar con clases puras de Java, conocidas como POJO (Plain Old Java Object) o con ManagedBean
de Modelo; estos no contienen lógica de la aplicación ni administran el flujo de la misma.
La vista define la UI con una jerarquía de componentes, utiliza la librería estándar de JSF, tecnologías como EL
(Expression Language), JSTL (Java Estándar Tag Library) para facilitar el despliegue de la información del
modelo. La tecnología utilizada por defecto en JSF 2.0 son los Facelets, que son páginas .xhtml.
El controlador maneja las interacciones del usuario y el flujo de la aplicación, se implementa con ManagedBean
de control. Recordar que un controlador realiza las siguientes funciones: recepción/validación de peticiones,
selección de la lógica a ejecutar y selección de la vista a en la que se presentará el resultado.

El lenguaje XHTML (Extensible HyperText Markup Language) es otro lenguaje de marcado de texto que se
caracteriza por la separación de la estructura de la información con la presentación de la página. XHTML se basa
en HTML, pero utiliza un archivo adicional con extensión CSS (Cascading Style Sheets) para definir la
presentación de la página. La presentación es la especificación del lugar en donde el navegador presenta cada
elemento de la página Web, del font, y de los colores de cada uno de los elementos a desplegar.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 16
Programación IV

Una de las características más importantes del XHTML es que tanto el texto como las imágenes pueden ser
hipervínculos.

Tecnología Facelets.
Los Facelets son la tecnología estándar de despliegue en JSF. Pueden ser hasta un 30% más rápido en el análisis
y elaboración de páginas de despliegue.
Una de sus principales ventajas, es que fueron creados tomando en cuenta el ciclo de vida de JSF.
Al ejecutar un Facelet, todos los componentes JSF se convierten a instancias Java y son administradas por un
Componet Tree (es una clase Java).
Todos los componentes JSF se derivan de la clase abstracta “javax.faces.component.UIComponent”.
El estado de los componentes (Componet Tree) puede almacenarse del lado del cliente o del lado del servidor.
Al utilizar Facelets es más sencillo encapsular código y así crear componentes reutilizables. Permiten crear
plantillas y definir más fácilmente nuevas vistas a partir de plantillas definidas.

Las etiquetas de JSF.

En JavaServer Faces todo se maneja con etiquetas <h: …. /> y <f: …./>.
Como JSF se basa en la filosofía de componentes que interactúan con el servidor de forma independiente, no se
manejan las etiquetas HTLM, como <form>, <input>, <select>, sino etiquetas para los componentes de JSF,
como son por ejemplo <h:form>, <h:inputText>, <h:selectOneListBox>.
Los componentes JSF brindan funcionalidad del lado del servidor, como conversiones de tipo, formateo, la
posibilidad de definir campos de texto obligatorios, entre otras.
En cualquier etiqueta se pueden acceder los métodos y los atributos de un Bean con la siguiente sintaxis:
#{nombreBean.atributoBean}
#{nombreBean.metodoBean()}

Las tres etiquetas básicas son:

<h:inputText … /> para campos de texto.
En el siguiente ejemplo, junto al campo de texto se pone la etiqueta nombre del campo.
<h: inputText pt:placeholder =”nombre del campo” />

<h:commandButton … /> para botones.

Es común utilizar los botones para la navegación implícita, es decir, en el action se pone el nombre de la vista a
la que se va a transferir el control. No se necesita poner la extensión, como en el siguiente ejemplo, en el que el
botón con la etiqueta “ir a página 2” nos lleva a la vista que se llama “pagina2”:
<h:commandButton value=”ir a página 2” action=”pagina2”>

El otro uso de commandButton es transferir el control hacia el método de un Bean, como en el siguiente
ejemplo, en el que al seleccionar el botón “Ingresar” el control pasa al método validarUsuario() del Bean
loginBean:
<h:commandButton value=”Ingresar” action=”#{loginBean.validarUsuario}”/>

______________________________________________________________________________________________________________
Ciclo 02 – 2023 17
Programación IV

<h:commandLink action=”PaginaDestino” value=”Etiqueta” /> para poner enlaces a otras páginas, en

action se pone el nombre de la página a la que se transfiere el control cuando se da clic en el enlace, y en value
las palabras que aparecen en el enlace

Flujo de navegación en JSF.

El flujo es el siguiente:

1. El framework inicia una petición “get” web a una página “index.html”.

2. Ya dentro del contexto de JSF, el usuario recibe el contenido de respuesta y envía nuevamente una
petición “post” o “get” al servidor web. En esta petición el usuario está solicitando algún recurso.
3. El servidor web recibe la petición y revisa los ManagedBean involucrados. Si es necesario crear una
instancia de ellos dependiendo de su alcance, si es necesario se llaman los métodos setters de las
propiedades del bean que se deben de llenar.
4. Se ejecuta el método que procesa la petición solicitada por el cliente. En este momento, ya deben estar
instanciados los ManagedBean involucrados en esta petición.
5. Se ejecuta la lógica de negocio con el objetivo de obtener el modelo de nuestra aplicación, es decir, la
información que se va a desplegar o gestionar dentro de nuestra aplicación.
6. Se selecciona el caso de navegación respectivo y se redirecciona a la vista correspondiente, que puede
ser un Facelet o un jsp.
7. La vista utiliza la información del modelo que le compartió la aplicación JSF para finalmente regresar la
respuesta solicitada al cliente.

Opcionalmente, como solicitud de la petición podría simplemente redireccionar a algún caso de navegación, es
decir, pasar del paso 2 al 6, simplemente para seleccionar una página a redireccionar.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 18
Programación IV

Por lo tanto, desarrollar una aplicación JSF requiere de las siguientes tareas:
 Establecer una correspondencia “petición-objeto FacesServlet”, ya que con la tecnología JSF es un
objeto de la clase FacesServlet el encargado de recibir la petición del usuario.
 Crear las páginas utilizando las bibliotecas de etiquetas JSP personalizadas.
 Definir la navegación entre páginas en el archivo de configuración correspondiente (faces-config.xml).
 Desarrollar los beans de apoyo.
 Añadir las declaraciones de los beans al archivo de configuración correspondiente (faces-config.xml).

La navegación en JSF (paso 6) permite movernos entre páginas de la misma tecnología.

Existen varios tipos de navegación:
 Estática: el valor de la siguiente vista o página está definido por un nombre fijo.
Es la navegación más sencilla, consiste en pasar de una página a otra.
En el siguiente código de ejemplo se asocia la página “homeSistema” a la acción del botón, es decir,
cuando el usuario seleccione el botón “Entrar” se desplegará la página homeSistema.xhtml.
<h:commandButton label=”Entrar” action=”homeSistema” />

No se recomienda la navegación estática en proyectos grandes, ya que se pierde la filosofía Modelo-

Vista-Controlador. La decisión de desplegar una página Web debe tomarse en el controlador, no en la
vista.

 Dinámica: el valor de la siguiente vista a seleccionar depende de la acción que ejecute el usuario y la
cadena de retorno del método “action” ejecutado.
En la navegación dinámica se ejecuta un método del Managed Bean asociado, cuando el usuario
selecciona un botón de la página Web. En este Bean se inicia el proceso de la información, y la página
destino se determina después de que se finaliza este proceso.

Existen varias formas de configurar la navegación:

 Navegación implícita: la salida especificada busca directamente una página con un nombre idéntico a la
cadena de salida en el directorio actual con la extensión de la página actual (xhtml ó jsp).

 Navegación explícita: se define la navegación dentro del archivo faces-config.xml, se debe agregar un
elemento XML que permita indicar de dónde proviene la petición, cuál es su salida y hacia qué página
debe dirigirse.

En JSF 2.0 la navegación explícita toma precedencia sobre la navegación implícita.

Esto quiere decir que únicamente al regresar una cadena busca en automático una página con un nombre idéntico
y si le encuentra toma preferencia y despliega esa vista, en lugar de buscar un caso de navegación dentro del
archivo de faces-config.

Navegación estática.
En la navegación estática, el elemento para definir cuál es la siguiente página a mostrar es una cadena y se le
conoce como salida o en inglés “outcome”.
La navegación estática aplica en los siguientes casos:
 No se requiere ejecutar código Java del lado del servidor, sino únicamente redirigir a otra página.
 Cuando no hay una lógica para determinar la siguiente página a mostrar.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 19
Programación IV

Un ejemplo de una navegación estática es al utilizar una página JSF que inicia una petición y vamos a indicar
por ejemplo, con un botón de tipo command una acción, en el cual estamos indicando la acción de login.
<h:commandButton label=”Entrar” action=”login” />

Esta acción del login como podemos observar, simplemente es una cadena, en este caso la siguiente página a
mostrar puede determinarse de dos maneras:
a. Outcome por defecto, buscar directamente la página login.xhtml, esta página se va a buscar en el mismo
directorio donde se encuentra la página que inició la petición.
b. Buscar el uutcome en el archivo faces-config.xml, encontrando el caso de navegación que determina la
siguiente página a mostrar.

Navegación dinámica.
Utiliza un método conocido como “action”, el cual tiene la lógica para determinar la salida u outcome.
Podemos observar un ejemplo:

En este caso estamos utilizando Expression Language y estamos utilizando un bean llamado login y llamamos a
un método verificarUsuario. Este método es el que va a tener la lógica para seleccionar la siguiente página
mostrar.
Si vemos la lógica del Managed Bean, verificamos que dependiendo de cierta condición puede regresar la
cadena “éxito” o la cadena “fallo”. A través de esta cadena se seleccionará finalmente la página siguiente a
mostrar, intentará buscar una página exito.xhtml dentro del mismo directorio, si no lo encontrará entonces
buscará dentro del archivo faces-config.xml un caso de navegación que tenga como outcome la palabra “éxito” o
la palabra “fallo” y dependiendo de esto seleccionará la siguiente vista a mostrar.

Reglas de navegación.
Para definir las reglas de navegación debemos utilizar el archivo faces-config.xml.
La estructura de este archivo es la siguiente:

______________________________________________________________________________________________________________
Ciclo 02 – 2023 20
Programación IV

En el tag <navigation-rule> definimos la regla de navegación

Dentro de este tag vamos a indicar primero cuál es la página de la cual proviene la petición (con el tag <from-
view-id>. En este caso estamos indicando la página inicio.xhtml, esa es la página que iniciará la petición.
Posteriormente podemos definir varios casos de navegación para esta misma página, ya que a partir de una
página puede dispararse una acción hacia diferentes páginas de JSF. La salida de cada uno de los casos de
navegación ya sea estática o dinámica tendremos que definirla dentro de estos casos de navegación. Para ello
vamos a utilizar el tag <from-outcome>. En este caso estamos utilizando la cadena “entrar”.
Finalmente lo que hacemos es definir la siguiente vista a mostrar si es que la salida de esta página de inicio
arrojó la cadena “entrar” y en este caso hará un redireccionamiento a la página login.xhtml.
Esta es la forma en que definimos un flujo en una aplicación de JSF.
Como resumen una página de origen puede tener como destino varias páginas e incluso reglas de navegación
genéricas. Un caso común de reglas genéricas es redirigir cualquier página a la página de inicio si es que se
requiere este caso de navegación.

Managed Beans.
Es una clase Java que sigue la nomenclatura de los JavaBeans. No están obligados a extender de ninguna otra
clase, esto tiene la ventaja que JSF es menos intrusivo que el uso de Struts.
Un Backing Bean es lo mismo que un Managed Bean, debido a que es una clase Java del lado del servidor;
aunque JSF no define una clasificación para Backing Beans, podemos definir las siguientes:
 Beans de Modelo: representan la capa Modelo en el patrón MVC.
 Beans de Control: representan la capa Controlador en el patrón MVC.
 Beans de Soporte o Helpers: contienen código por ejemplo de convertidores.
 Beans de Utilerías: se pueden utilizar para tareas genéricas, como obtener el objeto HTTP request

Uso de los Managed Beans.

Un Managed Bean se puede declarar de distintas maneras:
 Con anotaciones, antes del nombre de la clase: @ManagedBean
 Como Bean CDI (Contexts and Dependency Injection), antes del nombre de la clase: @Named. Debe
agregar un archivo llamado “beans.xml” en la carpeta “web/WEB-INF” (en la versión JAVA EE 8 es
opcional).
 En el archivo faces-config.xml: <managed-bean>…</managed-bean>

Alcance de los Managed Beans.

Existen diferentes ámbitos en los que puede operar un Bean. Los ámbitos más representativos, de menor a mayor
alcance, son: petición, vista, sesión y aplicación. Con la anotación de ámbito, se establece el alcance de los
métodos y atributos de un Bean.
Las anotaciones para los ámbitos más utilizados son las siguientes:
 @RequestScoped: persiste sólo durante la petición (request) del usuario. Cuando se envía la respuesta
correspondiente (response), se elimina la instancia del Bean. El constructor se ejecuta cada vez que la
página se solicita.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 21
Programación IV

 @ViewScoped: es algo intermedio entre RequestScoped y SessionScoped. El Bean existirá mientras la

vista está activa. El Bean permanece activo cuando una petición no requiere cambiar a otra vista, y
desaparece cuando el usuario navega hacia otra página. Esto es útil cuando se trabaja con Ajax.

 @SessionScoped: el Bean está activo durante toda la sesión del usuario. En otras palabras, mientras la
sesión exista, existe el Bean.

 @ApplicationScoped: el Bean existe mientras la aplicación esté corriendo en el servidor.

Declarando un Managed Bean con anotaciones.

Para declarar un Managed Bean con anotaciones es necesario poner antes del nombre de la clase, la anotación
@ManagedBean. En seguida se pone una anotación para declarar el alcance del Bean, posteriormente se declara
el nombre del Bean, con sus atributos privados y el constructor vacío. Cada atributo de un Bean debe tener su
método getter y setter.
JavaServer Faces administra los Managed Beans automáticamente, por eso deben cumplir con estas
características mencionadas.
Las tres acciones que JSF hace de manera automática con los Managed Beans son:
1. Los instancia (por eso deben tener el constructor vacío).
2. Controla su ciclo de vida (por eso deben incluir una declaración de ámbito).
3. Llama a los métodos getters y setters.

Para declarar el Managed Bean EjemploBean tenemos:

@ManagedBean
@RequestScoped
public class EjemploBean{
. . .
}

Cuando renombramos un Bean, se puede hacer referencia a él con otro nombre desde las páginas JSF, la sintaxis
para renombrar es la siguiente:
@ManagedBean(name=”nombreBean”)

______________________________________________________________________________________________________________
Ciclo 02 – 2023 22
Programación IV

Por ejemplo:
@ManagedBean (name=”Ejemplito”)
@RequestScoped
public class EjemploBean{
. . .
}

Los tres objetos JavaBean en la aplicación web.

Toda aplicación web hecha con JavaServer Faces tiene tres objetos que se instancian automáticamente:
 RequestBean: es un objeto que persiste sólo durante la petición del usuario (@RequestScoped).
 SessionBean: es un objeto que existe durante toda la sesión del usuario. Sólo hay un sessionBean por
cada usuario.
 ApplicationBean: es un objeto que existe mientras la aplicación se esté ejecutando en el servidor. Este
objeto lo comparten todas las instancias de la aplicación.

Ciclo de vida de JSF.

El ciclo de vida de JSF comienza con una petición de un usuario, el usuario solicita algún recurso de nuestro
servidor web.

1) La primera fase dentro de este ciclo de vida es el proceso de restauración o creación de la vista.
Si es la primera vez que solicita esta vista se va a crear cada uno de los componentes que representan las
etiquetas de nuestra página JSF y va a tener una clase correspondiente de Java que represente esa
etiqueta en JSF. Todas estas etiquetas son administradas por un componente principal llamado
“Component Tree” o árbol de componentes. En caso de que la petición haya sido “get” o sin parámetros,
el framework no tiene nada más que realizar y simplemente regresa la respuesta al cliente.

2) En caso contrario y que necesitemos procesar información, el paso dos es aplicar los valores de la
petición. En este paso los parámetros enviados son mapeados con cada uno de los componentes Java
correspondientes. Esto nos permitirá llenar la información que los usuarios están enviando a nuestra
aplicación Java.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 23
Programación IV

3) En el paso 3 lo que sucede es el procesamiento de validaciones y conversiones, es decir, en el paso 2 ya

se asignaron los valores correspondientes a nuestras clases Java. Sin embargo, en este punto todavía no
sabemos si esos valores son los adecuados o si es necesario convertirlos a cierto tipo de dato. Por ello, en
el paso 3 si alguna validación falla, el estado del Componente Java se marca como inválido y se pasa
directamente al Estado 6; esto únicamente sucede en caso de que hayamos encontrado algún error de
conversión o de validación.
Sin embargo esto nos garantiza que nuestra aplicación Java no va a continuar si es que tiene algún
problema de validación o de corrección de datos.

4) En caso de que no tengamos errores de validación, en el paso 4 lo que hace el framework es actualizar
los valores de nuestras clases de modelo, los valores de los componentes Java ya una vez validados y
convertidos en el paso 3 son puestos en los objetos de modelo utilizando los métodos “setters”
respectivos; es decir, que hasta este paso 4 es donde realmente el framework nos garantiza que esos
valores ya los podemos utilizar para operar. Por ejemplo si estamos enviando un dato de tipo fecha, en
este momento la fecha se puede convertir directamente a un tipo de fecha y no manejarlo como string ya
que normalmente así es como sucedía dentro del API de los servlets y los JSPs; cuando utilizábamos
esas tecnologías, nosotros éramos responsables de hacer este tipo de conversiones, en el caso de JSF
mucho de ese trabajo queda resuelto por el propio framework.

5) En el paso 5, ya que tenemos la información de modelo, procedemos a invocar nuestra aplicación, los
métodos que procesan las peticiones de nuestros usuarios. En este punto se ejecutan los métodos
“action” que están almacenados en los Managed Bean. Los métodos “action Listener” son llamados
antes que los métodos de tipo “action”.

6) Una vez que hemos procesado los métodos de nuestra aplicación se genera una respuesta respectiva
hacia el cliente. Con esto se concluye el ciclo de vida de nuestra aplicación JSF.

Internacionalización en JSF.
JSF tiene soporte total para la especificación “I18n” de Java, la especificación del idioma en una aplicación web.
Para definir un idioma debemos utilizar un archivo de propiedades. Estos archivos nos permiten especificar
nuestras etiquetas de las páginas web en varios idiomas:

Podemos observar en la figura que tenemos un archivo de mensajes con el idioma por default.
El idioma por default de la aplicación se puede especificar ya sea en el archivo faces-config o vía programática
en algún método “action” de un Managed Bean. Para ello debemos utilizar el objeto facesContext e
indirectamente vamos a utilizar el método “set-locate” y posteriormente utilizamos el método “set-locate”
indicando el código del lenguaje que vamos a utilizar.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 24
Programación IV

Entonces podemos observar que parte de la configuración del manejo de mensajes simplemente se define en
archivos de propiedades, cada uno de ellos contiene las etiquetas que se van a utilizar en nuestras páginas JSF
para desplegar las etiquetas en un idioma o en otro.
JSF puede cargar estas etiquetas de un archivo de propiedades también conocido como “Resource Bundle”.
En el archivo faces-config.xml debemos configurar el archivo a utilizar de la siguiente manera:

Por ejemplo, para utilizar el archivo de propiedades en las páginas JSF podemos hacerlo así:
<h:outputText value=”#{msg[‘form.usuario’]}” />
<h:commandButton value=”#{msg.enviar}” type=”submit” action=”login” />

Con esto lo que vamos a lograr es desplegar la etiqueta respectiva en el idioma que hayamos especificado. JSF
maneja la localización de errores y la información que ocurre en eventos como conversiones, validaciones y
otras acciones resultado del ciclo de vida de JSF dentro de este mismo concepto del manejo de mensajes.
JSF nos da la posibilidad de sobrescribir estos mensajes, sobre todo porque en ocasiones estos mensajes se
despliegan en el idioma nativo, es decir en inglés, y un requerimiento muy común es que los usuarios necesitan
ver esta información por ejemplo en español.
Por lo tanto para sobrescribir los mensajes internos con JSF, simplemente definimos un archivo de propiedades
(no importa el nombre), por ejemplo “jsf.properties”. Luego sobre escribimos los mensajes del sistema de JSF
que deseemos, por ejemplo:
javax.faces.component.UIInput.REQUIRED=Valor requerido

Así podemos definir cada una de las nuevas llaves a su valor respectivo en el idioma que estemos trabajando.
Finalmente para que JSF reconozca nuestro archivo con las modificaciones respectivas, lo que hacemos es
agregar en el archivo faces-config lo siguiente:

Manejo de eventos y librería estándar de JSF.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 25
Programación IV

JSF provee varias maneras de detectar cambios (value change) en los componentes, ya sea agregando un atributo
de tipo “valueChangeListener” al componente o como un elemento interno.
Los Listener en JSF nos permiten responder a eventos que suceden en la vista para enlazar el evento al
controlador y procesar el cambio en el componente. Estos componentes deben implementar la interfaz “editable
value”.
Vamos a revisar a continuación el código de la vista:

En la vista, como podemos observar tenemos un atributo llamado valueChangeListener dentro de nuestro
componente inputText; a su vez ese atributo valueChangeListener tiene asociado un Bean y ese Bean va a
mandar a llamar indirectamente el método “codigoPostalListener”. Entonces, una vez que el usuario haga algún
cambio en este texto se manda llamar el método “onchange” y automáticamente se manda llamar el código Java
respectivo asociado con este Bean vacanteForm.
Esto permite que de manera muy simplificada podamos mandar a llamar eventos del lado del servidor de Java
directamente asociados con las páginas JSF.

Una vez que hemos configurado nuestro componente, debemos agregar el método “action” en el Managed Bean
respectivo que está escuchando el cambio en nuestra vista JSF. Este será el código que tenemos que agregar a
nuestro Managed Bean:

Podemos observar que es un método de tipo público void y se llama exactamente igual que como lo tenemos en
el atributo valueChangeListener, es decir, codigoPostalListener y recibe un atributo. El atributo es
“valueChangeEvent”, por lo tanto, cuando el usuario hace algún cambio dentro de nuestro inputText, ese
cambio manda llamar un evento directamente a nuestra clase Java, en este caso al método codigoPostalListener
y sí podemos observar en la figura siguiente:

Cuando un usuario está capturando algún valor dentro del campo de código postal, en automático se llama este
método que está mapeado en nuestro Managed Bean, y este método puede regresar información respectiva,
como puede ser en este caso a través del código postal se calcula directamente la ciudad y la colonia asociada a
este código postal.
En este tipo de componentes es común utilizar el atributo “immediate=true”, ya que la idea es evitar las
validaciones de los demás componentes y procesar sólo el componente que realizó el cambio de contenido.

ActionListener.
JSF provee dos maneras de configurar la detección de eventos cuando un usuario ejecuta una acción de tipo
“submit”, ya sea agregando un atributo de tipo “actionListener” al componente JSF o como un elemento interno
dentro de este componente.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 26
Programación IV

Algunos componentes que pueden manejar este tipo de eventos son: h:commandButton y h:commandLink, por
ejemplo:
<h:commandLink actionListener=”#{vacanteForm.enviar}”/>

Como podemos observar tenemos un atributo actionListener y ese atributo tiene asociado un Bean y finalmente
se manda llamar el método enviar de este Bean.
Este botón es muy similar al manejo de formularios HTML, cuando hacemos un submit o envío de nuestro
formulario.
Una vez definido el atributo o elemento interno, se debe agregar el método action en el Managed Bean que
procesa la petición de la Vista:
public void enviar(ActionEvent actionEvent) { … }

Este método debe tener la siguiente firma: debe ser public void y debe de tener un argumento de tipo
actionEvent, de tal manera que una vez que el usuario presiona este botón dentro de la página JSF se manda
llamar el evento respectivo. Este tipo de componentes nos permitirá procesar formularios en nuestras páginas del
cliente.

Componentes en JSF.
El API de JSF provee varios componentes básicos para el despliegue de información HTML. La lista de
componentes HTML en JSF es bastante extensa por lo que podemos revisar el API de JSF para tener el detalle
completo de cada uno de ellos:

El API de JSF provee varios componentes core para el manejo de eventos, administración de componentes, entre
otros. La lista de componentes core de JSF de igual manera es bastante extensa, por lo que podemos revisar en el
API de JSF a más detalle cada uno de estos elementos:

______________________________________________________________________________________________________________
Ciclo 02 – 2023 27
Programación IV

Como podemos observar este tipo de componentes no arrojan como tal un resultado HTML sino que tienen que
ver directamente con el framework de JSF, con el ciclo de vida o con validaciones y conversiones que se aplican
a nuestros componentes HTML.

Arquitectura de componentes JSF.

Los componentes en JSF son más que simples etiquetas HTML. Estos componentes tienen mucha similitud con
componentes de tipo swing para aplicaciones de escritorio en Java.
Existen tres partes esenciales en un componente JSF:

a. La etiqueta misma de JSF: este es el código de nuestra página JSF y aquí es donde podemos configurar
eventos, etiquetas con la internacionalización, personalización de la apariencia del componente,
conversiones, validaciones, entre otras.
b. El despliegue del componente: este elemento representa el código que finalmente visualiza el cliente, en
caso de ser un cliente con un navegador web lo visualiza en HTML, el render kit por default de JSF de
hecho es un código en HTML.
c. El componente Java UI: esta es una clase de Java que representa el componente de la página JSF pero
desde el punto de vista de código Java; en la fase 1 del ciclo de vida de JSF restauración de la vista es
donde la etiqueta JSF se mapea con un componente Java de tipo UI y una vez que se mapea se agrega
este componente a la clase component Tree de la vista; por lo que podemos observar un componente de
JSF se compone de más elementos que simplemente una etiqueta HTML. Esto permite que un
componente creado en JSF sea reutilizable y además sea bastante robusto.

Component Tree en JSF.

En la figura siguiente podemos observar el flujo de una aplicación JSF, la cual está orientada a administrar el
código desde el lado del servidor:

______________________________________________________________________________________________________________
Ciclo 02 – 2023 28
Programación IV

El flujo podemos observar que comienza con nuestro cliente o navegador, únicamente recibe el código HTML
generado por su servidor Java. Una vez el cliente hace una nueva petición al servidor, el componen Tree se
sincroniza nuevamente. El código de las etiquetas JSF son convertidos o actualizados a su componente JSF de
tipo UI respectivo.
Por ejemplo: el componente h:inputText se convierte en un componente de tipo UI, el cual puede ser
manipulado directamente desde algún Managed Bean, entonces nuestra etiqueta finalmente genera elementos
Java y estos elementos ya se agregan a nuestro component Tree.
Una vez que se ha terminado con las fases del ciclo de vida de JSF, se envía nuevamente la respuesta al cliente
generando finalmente la respuesta HTML.
El component Tree tiene una duración de vida muy corta, normalmente durante el envío y la respuesta de la
petición, es decir, un alcance de tipo Request Response.

Componentes de selección en JSF.

El API de JSF provee de distintos tipos de componentes de selección, por ejemplo:

Los componentes JSF tales como h:selectOneMenu muestran una lista de datos, los elementos de esta lista se
conocen como “Select Items” (elementos de selección).
La lista de elementos de tipo “Select Item” ligada a una propiedad del Managed Bean es utilizada dentro de
nuestro componente JSF, por ejemplo:
<h:selectOneMenu>
<f:selectItems value=”#{coloniaHelper.coloniaSelectItems}” />
</h:selectOneMenu>

Podemos observar que nuestro componente de tipo “selectItems” está asociado con un componente Java en una
clase de tipo Managed Bean y el atributo a utilizar se llama “coloniaSelectItems”.
También podemos desplegar la lista de elementos JSF de la siguiente manera:
<h:selectOneMenu>
<f:selectItems>
<f:selectItems itemLabel=”Rojo” itemValue=”rojo” />
<f:selectItems itemLabel=”Verde” itemValue=”verde” />
<f:selectItems itemLabel=”Azul” itemValue=”azul” />
</f:selectItems>
</h:selectOneMenu>

En lugar de desplegar una lista completa, podemos ir agregando uno a uno los elementos o también extraídos
dinámicamente de atributos de nuestro Managed Bean.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 29
Programación IV

En JSF no es posible desplegar directamente una lista de elementos, como pueden ser un arreglo, una colección o
cualquier elemento que contenga varios datos. Esto se debe a que debemos de convertirlos precisamente a tipos
“selectItems” ya sea mostrándolos uno a uno o mostrándolos como una colección de objetos de tipo
“selectItems”.

Facelets y Templates en JSF.

Los Facelets es la tecnología estándar de despliegue en JSF.
Entre sus características tenemos:
Los Facelets eliminan completamente la necesidad de utilizar JSP´s.
Parte del desuso de los JSP y el uso de los Facelets se debe a que los Facelets utilizan un parser XML en
lugar del compilador de java de JSP.
Comparado con JSP, los Facelets crean un component Tree más ligero.
Los Facelets resultan hasta 30 % más rápidos en comparación con los JSP.
Los Facelets tienen soporte para templates y además también la creación de componentes compuestos es
mucho más simple al utilizar este tipo de tecnología.
Los Facelets también permiten el manejo dinámico del component Tree, tanto para agregar o eliminar
componentes.

Los Facelets no son JSP’s. Dentro de una página Facelet no es posible utilizar los siguientes taglib de JSP:

Sí es posible utilizar los tags de JSTL en los Facelets:

Templates con Facelets.

Una de las grandes ventajas de utilizar Facelets es que proveen un mecanismo bastante intuitivo para definir
regiones lógicas en una página JSF. Esas plantillas las vamos a utilizar para separar el layout o la distribución de
nuestra página y los datos de la misma.
Las plantillas definen regiones lógicas de una página JSF:

Por ejemplo, la sección de header, la sección de menú, la sección de contenido y la sección de pie de página.
De hecho, normalmente lo único que vamos a tener que cambiar en nuestra plantilla va a ser la sección de
contenido.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 30
Programación IV

Los elementos generales para utilizar las plantillas de Facelets son los siguientes:
 Template (plantilla): esta página será utilizada para controlar el layout (la disposición de los elementos)
en nuestra página JSF.
 Template-client: una vez que hemos definido la plantilla, debemos crear un cliente de esta plantilla, es
decir, una página que personalice su propia distribución (layout) a partir de la plantilla que implementa.
Los usuarios finales siempre accederán al Template-client, nunca accederán directamente a la plantilla
base.

Componentes compuestos.
La creación de nuevos componentes JSF requería de crear clases Java. Los Facelets permiten crear componentes
reutilizables combinando HTML, CSS, Javascript y también los tags de JSF. Esto permite la reutilización de
otros componentes es decir por ejemplo si ya creamos un componente. Otra ventaja es que con los Facelets
podemos definir un nuevo componente en un archivo XHTML, no hay necesidad de crear clases Java.
Los componentes compuestos son básicamente templates asociados a un tag library personalizado.
Para referenciar a un nuevo componente basta con importar el namespace en el XHTML. El namespace de
alguna manera es como si hiciéramos un import de una clase de Java, pero en este caso lo que vamos a hacer es
un import de nuestro componente de nuestra página JSF.

______________________________________________________________________________________________________________
Ciclo 02 – 2023 31