JavaServer FacesJavaServer Faces es una tecnología que fue diseñada para simplificar la construcción de interface de usuario para aplicaciones Web Java, uno de los puntos clave fue el apoyo de las herramientas creadas para este tipo de aplicaciones, JSF tiene el apoyo de IDE’s tales como eclipse, Netbeans, myEclipse, Oracle web, entre muchos otros más, además cuenta con un fuerte apoyo de servidores de aplicaciones java con el objetivo de soportar y desplegar las aplicaciones creadas en JavaServer Faces.

JavaServer Faces es el marco de aplicaciones web estándar para el desarrollo de aplicaciones empresariales java.

Al ser un estándar de java, esta teología cuenta con un apoyo muy fuerte de la industria de java, esta tecnología ha crecido bastante su uso a nivel mundial.

Se cuenta con un fuerte apoyo de IDE’s de Java, así como servidores de aplicaciones para su despliegue.

Características de JavaServer Faces El framework de JSF implementa el patrón de diseño MVC proporcionando un enfoque orientado a

eventos. Debido al número de componentes listos para utilizarse JSF agiliza el desarrollo de aplicaciones Web

para Java (RAD). JSF provee un API para crear componentes HTML complejos, incluyendo de manera embebida dentro

del componente, tecnología como JavaScript, CSS y HTML Integrado, esto permite crear componentes reutilizables.

Render-Kit. Los componentes pueden desplegarse no solamente en navegadores WEB sino también en dispositivos móviles u otro tipo de clientes.

Permite crear más fácilmente nuevos componentes por lo que existen varios frameworks que extienden el poder JSF incluyendo por ejemplo AJAX.

Las vistas en JSF pueden mostrase en distintos idiomas.

Características de JSF 2.0 Manejo de condiciones por default más inteligentes, esto aplica en casos de navegación simples los

cuales ya no se requiere integrarlos al archivo de configuración faces-config como era necesario en la versión 1.0

Manejo de anotaciones para varias configuraciones de este framework, esto simplifica en gran medida, el agregar un managed bean a nuestra aplicación web, evitando con ello la declaración en el archivo faces-config.

También se incluyó un soporte nativo para AJAX, la tecnología de AJAX ya es parte del ciclo de vida de JSF por lo que procesar peticiones asíncronas es más rápido que en la versión 1.0.

A diferencia de la versión 1.0, en la versión 2.0 ya tenemos soporte por default para el uso de la tecnología de Facelets, la tecnología de Facelets toma en cuenta el ciclo de vida de JSF a diferencia de los JSP’s, por ello los JSP’s quedaron en desuso y quedo como tecnología principal el uso de los Facelets.

Arquitectura JavaServer FacesEn primera instancia tenemos la capa del cliente, en la cual vamos a estar visualizando el resultado de nuestra aplicación de JSF, el cliente lo que va a visualizar es tecnología de HTML, hojas de estilo y JavaScript.

Una vez que el cliente empieza a interactuar con nuestra aplicación, tenemos posteriormente la Capa Web (JSF) en esta Capa, es donde precisamente trabaja nuestro Framework de JSF. El cual se compone de Managed Bean (Controlador), Facelet/JSP Tags (Vista), JavaBean (Modelo). Como podemos ver, es un modelo MVC.

Posteriormente tenemos nuestra capa de negocio, estas clases de negocio podemos implementarlas utilizando clases nativas de Java, podemos también utilizar EJB’s, o también podemos utilizar Spring como parte de la capa de Negocio.

Posteriormente para recuperar información de una base de datos, tenemos la Capa de Datos, aquí tenemos los objetos de Entidad, los cuales pueden ser trabajados con tecnologías como JPA o Hibernate.

Finalmente tenemos la comunicación con la BD y comienza de vuelta la respuesta hacia el cliente.

Patrón de diseño MVC con JSFJSF es un framework de aplicaciones Web que implementa el patrón de diseño MVC, con una clara separación de responsabilidades.

El Modelo contiene datos de la interfaz de usuario y es el responsable de almacenar los datos de la aplicación Web. Se puede implementar con clases puras de Java o también conocidas como POJO (Plain Old Java Object) o con Managed Bean de Modelo. No contienen lógica de la aplicación ni administran el flujo de la misma.

En cambio la vista, define la interfaz de usuario con una jerarquía de componentes, utiliza la librería estándar de JSF, también tecnologías como EL (Expression Language), JSTL (Java Standar Tag Library), etc. Esto para facilitar el despliegue de la información del modelo. La tecnología utilizada por default en JSF 2.0 son los Facelets por medio del lenguaje de Expresión de JSF es posible enlazar y utilizar los objetos de modelo he integrarlo con la vista para el despliegue de información.

El controlador maneja las interacciones del usuario y la navegación o flujo de la aplicación, se implementa con Managed Bean de Control.

Tecnología de los FaceletsLos Facelets incluyen las siguientes características:

Los Facelets son la tecnología estándar de despliegue en JSF 2.0. Los Facelets 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 Component Tree Todos los componentes JSF se derivan de la clase abstracta javax.faces.component.UIComponent El estado de los compnentes (Component Tree) pueden almacenarse del lado del cliente o del lado del

servidor.

Flujo de Navegación en JSF1. Como primer punto el Framework inicia una petición GET a una página por ejemplo nuestro

index.xhtml.2. una vez que ya estamos dentro del contexto de JSF, el usuario recibe el contenido de respuesta y envía

nuevamente una petición POST / GET al servidor WEB, en esta petición el usuario está solicitando cierto recurso.

3. El servidor web recibe la petición y revisa los managed bean involucrados en la petición, si es necesario crea una instancia de ellos dependiendo de su alcance y en este momento también si es necesario se mandan a llamar los métodos seters 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 de estar instanciados los managed bean involucrados en esta petición, si es que los hubiera.

5. Se ejecuta la lógica de negocio con el objetivo de obtener el modelo de nuestra aplicación, esto es la información que se va a desplegar o manipular dentro de nuestra aplicación.

6. Se selecciona el caso de navegación respectivo y se redirecciona a la vista correspondiente, en este caso la vista puede ser una página Facelet o puede ser un JSP.

7. La vista utiliza la información de modelo que le compartió la aplicación JSF para finalmente regresar la respuesta solicitada al cliente.

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

Requerimientos para JSF 2.0

Ejecución en Tomcat Instalar Java 5 o mayor Tomcat 6 o mayor (Cualquier servidor que soporte Servlets 2.5) Agregar los Archivos Jar de JSF 2.0

o Jsf-api.jaro Jsf-impl.jar

Descargar de Oracleo Mojarra o Apacheo MyFaces

Configurar web.xml Configurar faces-config.xml (opcional)

Ejecución en Glassfish o JBoss Instalar Java 6 o mayor Descargar Glassfish 3 o JBoss AS 6 o cualquier servidor que soporte Java EE 6 No se requieren librerías

o Java EE 6 tiene soporte integrado para JSF 2.0 Configurar web.xml Configurar faces-config.xml (opcional)

Nota: para generar un .xhtml, creamos un html file con el Template de New Facelet Composition Page

Lección 2Managed Bean en JSF

Java BeanUn Java Bean es una clase java que sigue las siguientes convenciones:

Tiene un constructor vacío Tiene atributos privados y por cada atributo tenemos un método get y un método set.

Partiendo del concepto de un java bean, los managed bean van a ser clases java que también cumplen con las convenciones de los java beans, sin embargo al trabajar con java server faces, vamos a configurarlos y declararlos de manera distinta.

Un managed bean es una clase java que sigue la nomenclatura de los JavaBeanso Los managed Beans no están obligados a extender de ninguna otra clase. o Esto a diferencia de frameworks como Struts, si era necesario depender de una clase llamada

action o de una clase llamada actionForm dependiendo del objetivo de la clase a procesar la petición en el caso de los managed bean esto ya no es necesario, esto tiene como ventajas que el framework de JSF sea menos intrusivo que de Struts.

Aunque JSF no define una clasificación para los Backing Beans, podemos definir las siguientes:o Un Backing Beans es lo mismo que un Managed Bean, debido a que es una clase de Java del

lado del servidor. Beans de Modelo: Representan el modelo en el patrón MVC. Beans de Control: Representan el control en el patrón MVC. Beans de Soporte o Helpers: Contienen código por ejemplo de Convertidores. Beans de Utilerias: Tareas genéricas, como obtener el objeto HTTP Request.

o Esta clasificación de Bean es únicamente para apoyarnos y poder clasificar el uso de nuestros managed beans.

Uso de los Managed Beans Un managed Bean se puede declarar de distintas maneras, por ejemplo:

Con anotaciones, antes del nombre de la clase:

o @ManagedBean

Como bean CDI (Contexts and Dependency Inyection), antes del nombre de la clase:o @Namedo Si utilizamos este concepto debemos agregar un archivo llamado beans.xml en la carpeta

web/WEB-INFo Los beans CDI están asociados a un contexto por ejemplo request, session, etc.o CDI especifica un mecanismo para inyectar beans, interceptar, filtrar u observar ciertos

eventos.o CDI también utiliza el concepto de inversion of control, el cual lo podemos entender como

fabrica de beans para obtener de manera indirecta, algún bean que necesitemos. El concepto de inversion of control, permite crear aplicaciones con bajo acoplamiento,

el bean debe de implementar la interfaz serializable.

En el archivo faces-config.xml:o <managed-bean>…</managed-bean>o Sin embargo en la versión 2.0 de JSF esto es opcional, es mas común utilizar anotaciones de

Managed Bean.

Alcance de los Managed BeansJSF provee los siguientes alcances o ámbitos para almacenar información en forma de mapa o tabla, eso quiere decir que almacenamos una llave y un valor asociado a esa llave.JSF 2.0 agrego algunos alcances llamados view y custom, el alcance de custom es simplemente una estructura de datos map que enlaza objetos, es decir valores con sus llaves respectivas, es decir sus keys, el tiempo de vida del map es administrado por el implementador, por eso este alcance es de tipo custom o personalizado.

Como podemos observar en la figura tenemos los alcances de request, view, session y application, cada uno de los alcances tiene un tiempo de duración, los cuales se indican por el tamaño de los círculos, por ejemplo el alcance de request tiene menos alcance que el de view y así sucesivamente.

Estos alcances nos van a servir para almacenar información de nuestra aplicación web y por lo tanto vamos a poder recuperarla durante el tiempo de vida de estos objetos, el objeto de request almacena información únicamente durante la petición de un usuario, una vez que esa petición a terminado, por ejemplo que ya solicito una nueva página la información que el usuario almaceno en el alcance de request se elimina de la memoria java, o lo que es lo mismo de la información del servidor web.

Posteriormente tenemos el alcance de view, este alcance es nuevo dentro de la especificación de JSF 2.0, este alcance nos permite guardar información en el servidor, siempre y cuando sea la misma página, es decir la misma vista, es muy útil si estamos utilizando conceptos como puede ser AJAX, ya que las peticiones AJAX son réflex parciales hacia la misma página HTML.

Posteriormente tenemos el alcance de session, este alcance de session nos permite almacenar información en el servidor durante el tiempo de vida de la session de un usuario, por lo tanto tiene mayor duración que los alcances de view y request.

Y finalmente tenemos el alcance de application, este alcance va a guardar información durante todo el tiempo de vida de nuestra aplicación web, este alcance nos va a permitir guardar información como puede ser la ip del usuario y cubrir requerimientos como puede ser, si un usuario ya se registró desde una maquina distinta,

podemos guardar su ip y denegar el acceso si este mismo usuario intenta conectarse desde otra pc al mismo sistema.

CDI y el alcance de los BeansEl concepto es muy similar al de los Managed Beans de JSF, sin embargo tiene algunas diferencias, JSF y CDI tienen en común los alcances de request, session y application, pero tienen como diferencia el alcance de view en el caso de JSF y el alcance de conversation de CDI, de hecho también las anotaciones para cada uno de estos alcances si es que vamos a declararlas se encuentran en distintos paquetes, en el caso de JSF se encuentran en javax.faces.Bean y en el caso del paquete de CDI se encuentran en javax.enterprice.Context además CDI agrega este alcance conversation, este alcance permite guardar información entre paginas relacionadas y la información almacenada es eliminada hasta que se cumpla cierta tarea.

Primer Ejemplo: Hola mundo

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core">

<f:loadBundle basename="resources.application" var="msg"/>

<head> v <title><h:outputText value="#{msg.welcomeTitle}" /></title></head>

<body><h3><h:outputText value="#{msg.welcomeHeading}" /></h3><p><h:outputText value="#{msg.welcomeMessage}" /></p></body></html>

resources/application.properties

# -- welcome --welcomeTitle=JSF Blank Application

welcomeHeading=Welcome!

welcomeMessage=This is a JSF blank application. \You can find the application.properties file with this message in the src/resources

folder.

Ejemplo 2: Model ManagedBeans

Saludo.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"xmlns:ui="http://java.sun.com/jsf/facelets"xmlns:h="http://java.sun.com/jsf/html"xmlns:f="http://java.sun.com/jsf/core">

<f:loadBundle basename="resources.application" var="msg" />

<head><title><h:outputText value="#{msg.welcomeTitle}" /></title></head>

<body><h:form>

<h:outputLabel for="nombre" value="Nombre:" /><h:inputText id="nombre" value="#{candidato.nombre}" /><h:message for="nombre" /><br/><h:commandButton value="Enviar" />

</h:form></body></html>

Clase Candidato.java

package mx.com.cadillacs.beans.model;

import javax.faces.bean.ManagedBean;import javax.faces.bean.RequestScoped;

@ManagedBean //estamos indiando el tipo de clase administrada por JSF@RequestScoped // El alcance de tipo request, se va a construir y destruir cada vez que hagamos una peticion a nuestro navegador.public class Candidato {

//Es requerido, un constructor vaciopublic Candidato(){

}

//Cada atributo debe de ser privado y tener sus metodos get/set publicos.private String nombre = "Escriba su nombre";

public String getNombre() {return nombre;

}

public void setNombre(String nombre) {this.nombre = nombre;

}}

Inyección de dependencias en JSF Esto sucede cuando un usuario solicita una pagina, en este caso la pagina de index.xhtml, esa pagina a su vez necesita de un objeto backing ManagedBean llamado VacanteForm.java y este a su vez tiene una dependencia con la clase Candidato.java.

Lo que hace el framework de JSF, es identificar si ya existen objetos de tipo backing Bean de tipo candidato en el alcance de request y si existen entonces regresa la referencia hacia la clase VacanteForm.java y a su vez este objeto una vez que está completo regresa la referencia hacia la página JSF y finalmente la página JSF index.xhtml puede hacer uso ya sea del objeto vacanteForm o del objeto candidato, dependiendo de la información.

Ejercicio 3: Vacante

vacante.xhtml

<html xmlns="http://www.w3.org/1999/xhtml"xmlns:ui="http://java.sun.com/jsf/facelets"xmlns:h="http://java.sun.com/jsf/html"

xmlns:f="http://java.sun.com/jsf/core">

<head><title>saludo</title></head>

<body><h:form>

<h:outputLabel for="nombre" value="Nombre:" /><h:inputText id="nombre" value="#{candidato.nombre}" /><h:message for="nombre" /><br/><h:commandButton action="#{vacanteForm.enviar}" value="Enviar" />

</h:form></body></html>

exito.xhtml

<head><title>exito</title></head>

<body><h:form>

Gracias #{candidato.nombre} por aplicar la vacante <br/><h:commandLink action="vacante">Regresar</h:commandLink>

</h:form></body></html>fallo.xhml

<head><title>Fallo</title></head>

<body><h:form>

Lo sentimos #{candidato.nombre}, ya se han cubierto las vacantes.<br/><h:commandLink action="vacante">Regresar</h:commandLink>

</h:form></body></html>

VacanteForm.java

package mx.com.cadillacs.beans.backing;

import javax.faces.bean.ManagedBean;import javax.faces.bean.ManagedProperty;import javax.faces.bean.RequestScoped;

import mx.com.cadillacs.beans.model.Candidato;

@ManagedBean@RequestScopedpublic class VacanteForm {

/* * La Clase va a tener una dependencia con la propiedad de candidato */@ManagedProperty(value = "#{candidato}")

private Candidato candidato;

public Candidato getCandidato() {return candidato;

}

public void setCandidato(Candidato candidato) { this.candidato = candidato;

}

//Metodo de flujo de control public String enviar(){

if(this.candidato.getNombre().equals("Juan")){return "exito"; //exito.xhtml

}else{return "fallo"; //fallo.xhtml

}}

}

Nota: La clase de candidato es la misma que en el ejercicio anterior.

Expression Language (EL) en JSF

Ejemplo de uso de Managed BeansPodemos crear managed Bean que posteriormente serán utilizados en las páginas JSF, comúnmente utilizaremos EL de JSF o también conocido como EL.

Para declarar un Bean, hemos visto que podemos utilizar la anotación:1. Creación del Bean

@ManagedBean@SessionScopedpublic class EmpleadoForm{…}

Uso en la página JSF con el EL (Expression Language)

Ahora como vamos a utilizar este bean dentro de nuestra página para obtener cierta información, vamos a utilizar EL y simplemente lo que vamos hacer es especificar el nombre del bean dentro del tag de nuestro EL.

Una vez especificado el nombre del bean lo que hacemos es especificar el nombre del atributo, que tengamos en nuestra clase y que tengamos la necesidad de mostrarlo en la pantalla JSF, sin embargo aquí podemos ver una diferencia, en este caso tenemos una ‘e’ minúscula comparada con la de la Clase, esta es la anotación de los ManagedBeans cuando estamos utilizando una clase, nuestra clase simplemente por nomenclatura la definimos con la ‘E’ mayúscula, pero cuando estamos utilizando un objeto de esta clase, las instancias de esta clase los declaramos con minúsculas.

#{empleadoForm.atributo}

2. Creación del Bean con nombre personalizado y notación CDI

@Namedpublic class EmpleadoForm{…}

En este caso podemos observar que agregamos la anotación de Named.

Posterior mente definimos nuestra clase y para utilizar este bean en nuestra página JSF la misma sintaxis que utilizamos creando nuestro ManagedBean.

#{empleadoForm.atributo}

Nota: Si el despliegue de nuestra aplicación se va a realizar en un servidor JEE 6, se recomienda utilizar CDI, en cambio, si se va a utilizar un servidor como Tomcat, el cual no tiene un soporte completo para la especificación JEE 6 podemos utilizar las anotaciones de JSF, esto se debe a que las anotaciones de CDI nos van a permitir simplificar la integración con tecnologías como puede ser EJB y JPA.

Inyección de dependencias

En muchas ocasiones una página JSF puede utilizar varios managed bean de ahí la necesidad de relacionar distintos managed bean, la inyección de dependencias, es un derivado de la inversión de control.

JSF soporta una inyección de dependencias simple.

La inyección se puede hacer de dos maneras:

Con anotaciones dentro del Managed Bean:o @ManagedProperty(value= “#{nombreBean}”)

Nota: para inyectar los beans, estos deberán de haber sido declarados con anterioridad.

También podemos inyectarlos, por medio del archivo faces-config.xml utilizando la etiqueta dentro de un managed bean:

o <managed-property>”“#{nombreBean}”</managed-property>

Nota: esta sintaxis ya es menos común en la especificación 2.0 debido a cómo podemos observar, definir una anotación he inyectar el contenido de un managed property dentro de otro managed bean es mucho más simple utilizando anotaciones.

Archivo faces-config.xmlEn la especificación de JSF 2.0 el archivo de faces-config se convierte en un archivo opcional, sin embargo este archivo tiene grandes características, las cuales podemos seguir utilizando sin ningún problema.

Uso y ventajas del archivo faces-config.xml Configuración centralizada, todos nuestros componentes los vamos a tener en un solo archivo

definidos y ahí podemos entender la configuración de nuestra aplicación JSF.o Desventaja, difícil saber si una clase tiene definido una anotación de Managed Bean o no.

Reglas de navegación, también en el archivo de faces-config, podemos definir reglas de navegación, es decir el flujo de nuestras páginas, en una aplicación JSF.

También podemos definir nuestros Managed Bean según hemos especificado. Podemos definir también la inyección de dependencias. Definir configuraciones regionales. Registrar validadores. Registro de listeners Etc…

Nota: Este archivo en una aplicación web debe de encontrarse dentro de la ruta de WEB-INF/faces-config.cml

Con el uso de anotaciones, cada vez es menos indispensable utilizar este archivo.

Ejemplo de anotaciones de Beans dentro de faces-config.xml

Nota: si no se especifica el alcance, este por default se encuentra en el alcance de request.

Expression Languaje (EL)El lenguaje de expresión (EL) de JSF nos permite simplificar el manejo de expresiones en la página JSF.

El lenguaje EL enlaza la vista con el modelo del patrón MVC.

Es decir al definir un bean, simplemente para desplegar esta información, en nuestra página JSF vamos a agregar la siguiente sintaxis

#{nombreBean.propiedad}

Lo que sucede al colocar esta expresión: Se busca el bean a utilizar en cierto alcance, primero en request, session y finalmente en alcance de

aplication. Una vez localizado se manda a llamar el método get o set de la propiedad indicada.

Objetos implícitos en JSF El lenguaje EL también permite acceder fácilmente a objetos implícitos (ya instanciados) en las páginas JSF, algunos ejemplos son:

Cookie: el cual es un Map facesContext: nos va a permitir acceder de manera indirecta a los objetos request, session o aplication. header: el cuale es un Map headerValues. Map param: Map paramValues. Map. request (JSF 1.2): ServletRequest or PortletRequest session (JSF 1.2): HttpSession or PortletSession requestScope: Map sessionScope: Map applicationScope. Map initParam: Map view: UIViewRoot

Operadores ELEl lenguaje EL cuenta con operadores para evaluar expresiones:

Nota: no utilizarlos mucho, ya que esto rompe el patrón de diseño MVC, al agregar lógica en nuestra vista.

Ciclo de vida de JSFEl ciclo de vida de JSF comienza con la petición de un usuario, el cual solicita un recurso de nuestro servidor web, la primera fase dentro de este ciclo de vida (1) 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 estos componentes que representan las etiquetas de nuestra página JSF y va a tener una clase correspondiente de Java que represente esta etiqueta en JSF, todas estas etiquetas son administradas por un componente principal llamado ‘component tree’ o ‘arbol de componentes’ en caso de que la petición haya sido get o sin parámetros, en este caso el framework no tiene nada más que realizar y simplemente regresa la respuesta hacia el cliente, en caso contrario y que necesitemos procesar información, (2) el paso 2, 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, (3) en este paso se realiza 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 datos, por ello en este paso 3 si una validación falla, el estado del componente se marca como invalido y se pasa directamente al estado (6) esto sucede solamente 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. En caso de que no tengamos errores de validación de datos, pasamos al paso (4) el cual actualiza 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 seters respectivos, es decir que hasta el 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 dato Date y no seguir manejándolo como un String ya que normalmente así es como sucedía dentro del Api de los servlets / JSP, cuando utilizábamos esas tecnologías nosotros éramos responsables de hacer ese tipo de conversiones, en el caso de JSF mucho de ese trabajo queda resuelto por el propio

Framework, en el paso (5) ya que tenemos la información de modelo, procedemos a invocar nuestra aplicación o lo que es lo mismo 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 actionListener son llamados antes que los métodos de tipo action. 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 de JSF, es posible crear clases JSF para la depuración de las faces paso a paso para ello debemos implementar la interface faces listener y se debe de registrar en el archivo de faces-config.xml