JSF Aplicaciones Distribuidas

2

Contenidos

•  Introducción

•  Arquitectura

•  Componentes UI

•  Renders

•  Eventos

•  Validadores

•  Backing beans

•  Internacionalización

•  Conversores

•  Navegación

•  Ciclo de Vida

•  Fichero configuración

3

Introducción

•  JavaServer Faces es una especificación que define un framework web para la creación de aplicaciones

•  Permite: •  gestión de componentes gráficos

•  manejo de eventos en el servidor

•  validación de entradas de usuario

•  asociación entre el modelo de datos y el interfaz de usuario

•  gestión del flujo entre páginas

•  etc…

4

•  Necesidad de adoptar el concepto RAD para desarrollar aplicaciones web.

•  En las herramientas RAD observamos cuatro capas: •  una arquitectura de componentes subyacente

•  un conjunto de artilugios o widgets estándar

•  una infraestructura de aplicación

•  la herramienta en sí misma.

5

•  JavaServer Faces define tres capas: •  una arquitectura de componentes,

•  un conjunto estándar de widgets (literalmente artefactos, aunque son componentes) de interfaz de usuario (UI)

•  una infraestructura de aplicación.

•  La arquitectura de componentes de JSF define un modo común de construir componentes de interfaz de usuario.

•  Proporciona componentes de interfaz de usuario (botones, hiperenlaces, checkboxes, campos de texto, etc), pero también establece la base para componentes de terceros.

6

•  Los componentes están orientados a eventos, así que JSF permite procesar eventos generados por el cliente (por ejemplo, cambiando el valor de un campo de texto o haciendo click sobre un botón).

•  Debido a que las aplicaciones basadas en web, a diferencia de las de escritorio, deben con frecuencia satisfacer a múltiples clientes (como navegadores de escritorio, teléfonos móviles, o PDAs), JSF tiene una arquitectura capaz de mostrar componentes de diferentes maneras.

•  También tiene facilidades extensibles para validar entradas (la longitud de un campo, por ejemplo) y convertir objetos a y desde cadenas de texto o strings.

7

•  JSF se ejecuta en el servidor, en un contenedor de servlets y muestra código HTML u otro lenguaje de marcas al cliente. •  Si se pulsa un botón en una aplicación Swing, se

disparará un evento que se puede manejar directamente en el código que reside en el escritorio.

•  Pero, los navegadores web no saben nada sobre componentes JSF o eventos, sólo saben cómo mostrar HTML.

8

•  Cuando se hace click en un botón de una aplicación JavaServer Faces, se genera una petición para ser enviada desde el navegador web al servidor

•  JSF es responsable de traducir la petición a un evento que puede ser procesado por la lógica de la aplicación en el servidor.

•  También es responsable de asegurarse de que todo componente de interfaz de usuario definido en el servidor, se muestre apropiadamente en el navegador.

Desarrollo de Aplicaciones Distribuidas 9

•  Principales elementos de la tecnología JavaServer Faces son:

•  Un API y una implementación de referencia para representar componentes de interfaz de usuario (UI) y manejar su estado, manejar eventos, validar en el lado del servidor y aplicar una conversión de datos, definir la navegación entre páginas, soportar internacionalización y accesibilidad y proporcionar extensibilidad para todas estas características.

•  Una librería de etiquetas JavaServer Pages (JSP) personalizadas para dibujar componentes UI dentro de una página JSP.

10

•  Permite: •  Conectar eventos generados en el cliente a código de

la aplicación en el lado del servidor.

•  Mapear componentes de interface de usuario a una página de datos del lado del servidor.

•  Construir un interface de usuario con componentes reutilizables y extensibles.

•  Grabar y restaurar el estado del interface de usuario más allá de la vida de las peticiones de servidor.

11

Tecnologías subyacentes

•  Todas las aplicaciones JSF son aplicaciones web Java estándar. •  Protocolo HTTP mediante el API Servlet y algún conjunto de

tecnologías de visualización como JSP

•  La tecnología de visualización se usa para definir componentes de UI (componentes que interactúan con código Java).

12

•  La arquitectura de componentes de JSF se vale de beans de respaldo o backing beans (JavaBeans) para propiedades y manejo de eventos

•  Los JavaBeans son componentes Java que se utilizan para crear los componentes de UI de JSF

•  JSF usa HTTP que es sin estado •  JSF permite abstraer a los programadores de este protocolo

(no maneja directamente peticiones y respuestas)

13

•  Los componentes de JavaServer Faces están diseñados para trabajar con backing beans.

•  Un backing beans define las propiedades y la lógica de manejo asociadas con los componentes de interface de usuario utilizados en una página.

•  Cada propiedad del bean está unida a un componente o a su valor.

•  Un backing beans también define un conjunto de métodos que realizan funciones para el componente (p.e. validar los datos del componente, manejar los eventos que dispara el componente, y realizar el procesamiento asociado con la navegación entre páginas cuando el componente se activa)

14

•  Uno de los principales objetivos de JSF es el de evitar estar ligado a una tecnología de visualización concreta.

•  Tanto JSP como JSF son tecnologías Java estándar.

•  La implementación de referencia JSF viene con una implementación de JSP y JSF trabaja sobre JSP.

•  En JSF 2.0 se sustituye JSP por Facelets

15

Patrón Modelo-Vista-Controlador

•  JavaServer Faces emplea una variación de MVC

•  Model-2 (específica para web): •  El modelo puede constar de objetos Java “de toda la

vida” (POJOs), EJBs, u otra cosa. •  La vista pueden ser JSPs u otra tecnología de visualización. •  El controlador se implementa siempre como un servlet.

•  El controlador JSF es un servlet FrontController llamado FacesServlet

•  Emplea ficheros de configuración y un conjunto de manejadores de acción (Action Handlers).

16

•  El FacesServlet recibe peticiones de clientes web y ejecuta un conjunto lógico de pasos para preparar y servir una respuesta

•  Un action handler es simplemente un método de un JavaBean que no tiene parámetros y retorna un String. resultado •  Retorna un (como por ejemplo “éxito” o “fallo”).

•  El fichero de configuración define el flujo de interfaces de usuario, entre otras cosas.

17

18

Arquitectura

•  Elementos de la arquitectura: •  Componente UI: Un objeto con estado, mantenido en el servidor, que

proporciona funcionalidad específica para interactuar con un usuario final. Son javabeans con propiedades, métodos y eventos. Organizados en una vista (árbol de componentes visualizado como una página).

•  Renderer: Responsable de mostrar un componente UI y traducir una entrada de usuario al valor del componente. Los renderers pueden ser diseñados para trabajar con uno o más componentes UI, y un componente UI se puede asociar con muchos renderers diferentes.

•  Validador: Responsable de asegurar que el valor introducido por un usuario es aceptable. Uno o más validadores pueden ser asociados con un sencillo componente UI.

•  Backing beans: Javabeans especializados que coleccionan valores de componentes UI e implementan métodos oyentes de eventos. También pueden mantener referencias a componentes UI.

•  Conversores: Convierte el valor de un componente a/desde un String para visualizar. Un componente UI puede ser asociado con un convertidor sencillo.

•  Events y listeners (eventos y oyentes): JSF utiliza el modelo evento/oyente de javabeans (también utilizado por Swing). Los componentes UI (y otros objetos) generan eventos, y pueden registrarse oyentes para manejar esos eventos.

•  Mensajes e internacionalización: La información que se visualiza de vuelta al usuario. Cualquier parte de la aplicación (beans de respaldo, validadores, convertidores, etc) pueden generar información o mensajes de error que pueden ser mostrados al usuario.

•  Navegación: La habilidad de moverse de una página a la siguiente. JSF tiene un potente sistema de navegación que está integrado con oyentes de evento especializados.

19

20

21

•  Los componentes de interface de usuario, que están contenidos en una vista, actualizan beans y generan eventos basados en entradas de usuario.

•  Los renderers muestran componentes, y también pueden generar eventos y mensajes.

•  Los convertidores traducen y formatean el valor de un componente para la visualización, y también generan mensajes de error.

•  Los validadores verifican el valor de un componente y generan mensajes de error.

•  Los beans contienen oyentes de evento y métodos de acción, que son oyentes de evento que están especializados en la navegación.

•  Los oyentes de evento consumen eventos y pueden manipular la vista o ejecutar objetos del modelo, que desempeñan la lógica de la aplicación

22

•  Los métodos de acción pueden hacer todo lo que los oyentes de evento pueden hacer, pero también devuelven un resultado que es usado por el sistema de navegación.

•  El sistema de navegación usa este resultado para seleccionar la siguiente vista a mostrar al usuario.

•  La mayoría de los elementos generan un mensaje o un evento (así es como JSF se comunica). •  Los eventos representan entradas de usuario u operaciones de la

aplicación.

•  Los mensajes indican errores o notificaciones de la aplicación.

23

Componentes UI

•  Objetos con estado, mantenidos en el servidor, que proporcionan funcionalidad específica para la interacción con el usuario final

•  Se construyen sobre la base de javabeans

•  Se ejecutan en el lado del servidor, no en el cliente

•  Estrategia de desarrollo basado en componentes (RAD)

•  El aspecto de un componente es la manera en la que se renderiza (diferentes visualizaciones para un mismo componente)

24

•  Los componentes UI tienen que recordar sus valores, o estado. Los componentes JSF gestionan esto automáticamente evitando esa tarea al desarrollador.

•  Los componentes JSF pueden recordar valores entre peticiones porque el framework mantiene un árbol de componentes de interface de usuario para una página en particular

•  El árbol de componentes, llamado vista, es la representación interna de la página JSF •  Utilizar “Vista” en lugar de “Página” subraya el hecho de que la

representación del usuario no tiene que ser una página web HTML siempre

25

Desarrollo de Aplicaciones Distribuidas 26

•  Cada componente en el árbol se identifica con un identificador de componente.

•  El identificador componente puede ser establecido por el desarrollador, y si no se establece ninguno, será generado automáticamente.

27

Renderers

•  Se encargan de la visualización gráfica de un componente

•  JSF proporciona un render kit estándar para HTML 4.01 •  Otros render kit podrían generar un “look and feel” diferente:

WML, SVG, etc..

•  Se separa el concepto de componente del concepto de renderer •  P.E.: un componente UICommand puede representarse como un

hipervínculo HTML o como un botón HTML.

•  En JSP, el tipo de renderer se indica mediante la incrustación de una etiqueta específica de tipo de render •  p.e.: <commandHyperlink/> y <commandButton/>

28

29

30

•  JSF tiene un render kit por defecto, (se expone a través de la propiedad renderKitId): •  public String getDefaultRenderKitId(); •  public void setDefaultRenderKitId(String renderKitId);

•  Se configura en el fichero de configuración JSF, y el valor por defecto es “HTML_BASIC” •  RenderKitFactory.HTML_BASIC_RENDER_KIT

•  El desarrollador puede personalizar los Renderers de un RenderKit existente o crear su propio RenderKit

•  El desarrollador puede definir un componente personalizado

31

Eventos

•  JSF utiliza el modelo de eventos y oyentes (event/listener) de javabeans.

•  Los componentes de interface de usuario y otros componentes generan eventos y oyentes que pueden ser registrados para manejar esos eventos

•  JSF integra la lógica de aplicación asignando los oyentes apropiados a componentes que generan los eventos que los oyentes comprenden (no hay peticiones y respuestas)

32

•  Hay cuatro eventos estándar:

•  eventos de cambio de valor (value-change events): se disparan cuando el usuario cambia el valor de un componente que es un control de entrada.

•  eventos de acción (action events): se generan cuando un usuario activa un componente de comando como un botón.

•  eventos de modelo de datos (data model events): se disparan cuando un componente de datos selecciona una fila para procesamiento.

•  eventos de fase (phase events): se ejecutan cuando JSF procesa una petición HTTP

33

•  JSF Expression Language (EL) •  Basado en el EL incluido en JSP 2.0

•  EL proporciona un conjunto de objetos implícitos que permiten al desarrollador acceder a parámetros de la petición, cabeceras HTTP, etc.

•  Se puede utilizar EL para sentencias lógicas y matemáticas, y también es posible mezclar valores literales con expresiones

34

•  Diferencias entre JSF EL y JSP 2.0 EL: •  JSF utiliza el signo (#) para marcar el principio de una expresión,

en vez del símbolo ($).

•  Las expresiones JSF pueden ser también de dos vías. En otras palabras pueden o recuperar el valor de una propiedad o actualizarla.

•  JSF EL también te permite referenciar métodos de objetos.

•  Algunas características específicas de JSP no están disponibles, como el ámbito de página.

•  Las funciones JSP EL no están soportadas oficialmente

35

•  Se puede utilizar JSF EL para enlazar componentes a objetos que exponen propiedades javabean, colecciones, y tipos de datos sencillos.

•  EL puede también ser utilizado para referenciar métodos y crear sentencias lógicas o numéricas. También soporta sentencias anidadas

36

Eventos de cambio de valor

•  Se gestiona con oyentes valuechange. <h:inputText valueChangeListener="#{myForm.processValueChanged}"/>

<h:panelGrid binding="#{myForm.changePanel}" rendered="false">

...

</h:panelGrid>

public void processValueChanged(ValueChangeEvent event){

HtmlInputText sender = (HtmlInputText)event.getComponent();

sender.setReadonly(true);

changePanel.setRendered(true);

}

•  El método oyente del evento cambiará la propiedad readOnly del emisor (en este caso, el componente HtmlInputText) a true de modo que el usuario no pueda editar su contenido.

•  Entonces cambiará la propiedad rendered del componente HtmlPanelGrid (que está ligada a la propiedad changePanel) a true de modo que será visible cuando la página es redibujada.

37

Eventos de acción

•  Los componentes que generan eventos de acción, también llamados action sources, incluyen controles como botones o hiperenlaces.

•  Los eventos de acción se manejan por oyentes de acción (action listeners)

•  Dos tipos de oyentes de acción: los que afectan a la navegación, y los que no: •  Los que afectan a la navegación generalmente llevan a cabo algún

tipo de procesamiento y luego devuelven un resultado lógico que usa el sistema de navegación de JSF para seleccionar la siguiente página

•  Los que no afectan a la navegación generalmente manipulan componentes en la vista en curso, o llevan a cabo algún procesamiento que cambia objetos de modelo o propiedades del beans, pero no modifican la página en curso a la que el usuario está accediendo

38

•  Los oyentes de acción delegan todo su trabajo a métodos de acción (action methods) en beans, así que el desarrollador puede tener métodos de acción diferentes manejando partes diferentes de su aplicación

•  Cuando un componente dispara un evento de acción, este oyente de acción por defecto determina su cadena de resultado, por ejemplo: “menuprincipal”, “exito”, “fallo”.

39

•  Dos tipos básicos de salidas: estática y dinámica •  Las salidas estáticas son cadenas constantes que se

declaran con el componente <h:commandButton type="submit" value="Login" action="exito“ immediate="true"/>

•  Las salidas dinámicas son cadenas devueltas por métodos de acción <h:commandButton type="submit" value="Login" action="#{loginForm.login}"/>

public class LoginForm

{

public String login()

{ if (...) {return "exito";}

else { return "fallo";}

}

40

•  Cuando se necesita ejecutar lógica de aplicación que no está asociada con la navegación, puede asociar un método oyente de acción con un componente. •  los oyentes de acción tienen acceso al componente que disparó el

evento (mediante event)

<h:commandButton id="redisplayCommand" type="submit" value="Redisplay“ actionListener="#{miForm.doIt}"/>

public void doIt(ActionEvent event){

HtmlCommandButton button = (HtmlCommandButton)event.getComponent();

button.setValue("Hecho!");

}

41

Eventos de modelo de datos

•  Ejemplo: componentes que muestran una lista de elementos en una tabla, como por ejemplo un HtmlDataTable

•  Sus oyentes de evento deben implementar una interface Java

•  Los eventos son disparados por una instancia DataModel, que es un objeto de modelo usado internamente por componentes relacionados con datos

•  DataModel son envolturas para listas, arrays, result sets, y otras fuentes de datos.

42

•  Debido a que el evento es técnicamente disparado por un objeto del modelo en lugar de por un componente, no se puede registrar un oyente sobre el componente mismo en JSP.

•  Hay que registrarlo en el código Java (clase interna anónima)

FacesContext facesContext = FacesContext.getCurrentInstance();

dataTable = (HtmlDataTable) facesContext.getApplication().createComponent(HtmlDataTable.COMPONENT_TYPE)

DataModel myDataModel = new ResultSetDataModel(myResultSet);

myDataModel.addDataModelListener(

new DataModelListener() {

public void rowSelected(DataModelEvent e){

FacesContext.getCurrentInstance().getExternalContext().log("fila seleccionada:" + e.getRowIndex()); }

});

dataTable.setValue(myDataModel);

43

Eventos de fase

•  Siempre que una aplicación JSF recibe una petición, pasa a través de un proceso de seis pasos denominado Ciclo de vida de Procesamiento de Petición •  Durante este proceso, JSF restaura la visualización

pedida, traduce los parámetros de petición a valores componentes, realiza la validación de entradas, actualiza beans de respaldo u objetos de modelo, invoca oyentes de acción, y devuelve una respuesta al usuario.

•  Los eventos de fase se generan antes y después de cada paso, o fase, de este ciclo de vida.

44

•  Es necesario que se implemente una interface Java para registrar oyentes de evento

lifecycle.addPhaseListener( new PhaseListener(){

public void beforePhase(PhaseEvent event) {priceQuote = QuoteService.getLatestQuote(currentQuoteId);}

public void afterPhase(PhaseEvent event){}

Public PhaseId getPhaseId(){ return PhaseId.RENDER_RESPONSE; }

})

•  Ejemplo de registrar un oyente de fase que se ejecuta antes de que una vista sea mostrada •  Lifecycle representa al ciclo de vida del procesamiento de la petición. •  La propiedad phaseId del oyente indica al ciclo de vida cuándo debería

procesar eventos (la fase Renderizar Respuesta).

45

Validadores

•  Son los responsables de asegurar que los valores introducidos son aceptables.

•  Se puede asociar uno o más validadores al mismo componente de interface de usuario

•  3 formas de validación:

•  A nivel de componentes de interface de usuario (validadores estándares predefinidos): se usa para validaciones simples (p.e. como asegurar que se ha introducido un valor en un campo obligatorio)

•  Mediante métodos validadores en los beans (útil cuando necesitamos validar uno o más campos de un formulario y no queremos compartir esa lógica con otros componentes)

•  Mediante clases validadoras (útiles para casos genéricos como la longitud de un campo o el rango de un número).

46

•  Validadores estándar (predefinidos) en JSF: •  campo con valor requerido •  validadores de la longitud de una cadena •  validadores de rango para enteros y decimales.

•  Se pueden crear validadores propios

•  Cuando un validador encuentra un error, añade un mensaje de error a la lista de mensajes actual, que es un componente que muestra mensajes relacionados con componentes o con la aplicación.

47

•  Ejemplos: •  validador estándar

<h:inputText id="userNumber" value="#{NumberBean.userNumber}" required="true"/>

•  validador que recurre a un bean <h:inputText id="emailInput" validator="#{registrationBean.validateEmail}“ value="#{registrationBean.email}/>

•  Clases validadoras <h:inputText id="age" value="#{resumeBean.age}" required="true">           <f:validateLongRange minimum="16" maximum="64"/>  </h:inputText> 

48

Modelo (uso de beans)

•  JavaServer Faces implementa una variante del Modelo Vista Controlador (MVC) denominada Modelo 2.

•  Este modelo potencia la separación entre la vista y el modelo, y la interacción entre ambos que viene determinada por el controlador.

•  El modelo vendría a estar formado por clases de acceso a bases de datos (DAO o Hibernate), EJB, servicios web, etc…

•  Los beans de respaldo son los objetos que realizan función del controlador: controlar la interacción entre la interface de usuario y el modelo.

49

•  Los beans generalmente contienen propiedades a recuperar y métodos de oyentes de eventos, que procesan esas propiedades.

•  También pueden manipular la interface de usuario o realizar algún tipo de procesamiento en la aplicación. •  Algunas herramientas de desarrollo generan clases

bean de respaldo automáticamente cuando se crea una nueva página.

50

•  JSF permite asociar beans de respaldo con componentes de interfaz de usuario de forma declarativa (con marcas y no código)

•  Se asocia un componente con el bean de respaldo a través del lenguaje de expresiones (EL) de JSF

<h:outputText id="helloBeanOutput" value="#{helloBean.numControls}"/>

•  Cuando cambia el valor del componente, cambiará el valor del bean de respaldo y viceversa, porque ambos están sincronizados.

51

•  Se puede enlazar una propiedad de un componente con la de un bean de forma que se puede manipular la vista con código Java

<h:panelGrid id=“aControlPanel" binding="#{helloBean.controlPanel}“ columns="20" border="1" cellspacing="0"/>

•  Dede el bean se puede manipular el componente, haciendo uso de la propiedad controlPanel.

52

•  Los beans son declarados en el fichero de configuración (faces-config.xml): se puede especificar qué objetos estarán disponibles a lo largo del ciclo de vida de la aplicación.

<managed-bean>

<managed-bean-name>brokeUser</managed-bean-name>

<managed-bean-class>org.jia.examples.UserBean</managed-bean-class>

<managed-bean-scope>request</managed-bean-scope>

<managed-property>

<property-name>firstName</property-name> <value>Joe</value>

</managed-property>

<managed-property>

<property-name>favoriteAnimal</property-name> <null-value/>

</managed-property>

</managed-bean>

•  O se puede declarar y crear la clase en codigo Java (.java) <managed-bean> 

<managed-bean-name>userBean</managed-bean-name>  <managed-bean-class>org.jia.examples.UserBean</managed-bean-class>  <managed-bean-scope>session</managed-bean-scope> 

</managed-bean>

53

Internacionalización

•  JSF conocerá la localización del usuario mediante la aplicación cliente (el navegador web indicará en las cabeceras HTTP las lenguas que soporta y la que tiene por defecto)

•  Los códigos de los idiomas se ponen en minúscula, mediante cadenas de dos letras definidas por la Internacional Organization for Standardization (ISO).

54

•  Tareas:

•  1 - Indicar en JSF (faces-config.xml) las lenguas que soporta y la región en la que se aplican

•  2 - Crear al menos un fichero de recursos con las cadenas de texto en los lenguajes deseados

•  3 - Cargar el fichero de recursos y referenciar las cadenas de los ficheros de recursos en vez de escribirlas directamente en las páginas

55

•  1. Indicar JSF qué idiomas debería soportar. •  faces-config.xml <application>

<locale-config>

<default-locale>es</default-locale>

<supported-locale>en</supported-locale>

<supported-locale>en_US</supported-locale>

</locale-config>

<message-bundle> MensajesPersonalizados </message-bundle>

</application>

•  La lengua seleccionada en el cliente tiene preferencia y si no se esta en las indicadas con la etiqueta <locale-config> del cliente, se recurre a la lengua por defecto.

56

•  2. Crear ficheros de recursos •  Ficheros con el texto en los distintos lenguajes soportados •  resource bundles: Se componen de líneas formadas por los pares

clave/valor.

•  Igual nombre excepto por un sufijo que debe ser acorde con el lenguaje al que traduce y que precede a la extensión.

•  Los mensajes contenidos en los ficheros se pueden parametrizar

MensajesPersonalizados_es.properties halloween=Todos los días son como el Día de las Brujas.

numberOfVisits=Nos ha visitado {0} veces, {1}. ¡que buena onda!

toggleLocale=Traducir a Ingles

helloImage=../images/hola.gif

57

•  3. Cargar recursos y usar las cadenas contenidas

•  Cargar el fichero de recursos (resource bundle) con el nombre que tienen en común los ficheros de recursos de los diferentes idiomas, pero excluyendo el sufijo que indica el lenguaje concreto y la extensión

<f:loadBundle basename=" MensajesPersonalizados" var="bundle"/>

•  Referenciar las cadenas

<h:outputFormat value="#{bundle.numberOfVisits}">

<f:param value="#{user.numberOfVisits}"/>

<f:param value="#{user.firstName}"/>

</h:outputFormat>

58

Conversores

•  Convierten el valor de un componente desde y a una cadena para mostrar por la pantalla.

•  Un componente de interface de usuario puede ser asociado con un único conversor.

•  Traducen un objeto a una cadena para visualizar, y desde una cadena de entrada en un objeto

•  JSF tiene conversores para tipos comunes como fechas y números •  Pero también podemos crear nuestros propios conversores

59

•  p.e.: Conversor de fecha: <h:outputText value="#{user.dateOfBirth}">

<f:convertDateTime type="both" dateStyle="full"/>

</h:outputText>

•  JSF dispone de conversores por defecto si no se indica nada

•  Formas de definir un conversor:

•  Anidando (permite parametros): <h:outputText value="#{user.dateOfBirth}">

<f:convertDateTime type="date" dateStyle="medium"/>

</h:outputText>

•  Atributo: <h:outputText value="#{user.creditCardNumber}" converter="creditcard"/>

60

Navegacion

•  La navegación es la habilidad de pasar de una página a la siguiente.

•  JSF tiene un sistema de navegación que se integra con oyentes de eventos especializados.

•  El manejador de navegación (navigation handler) es el responsable de decidir qué página se va a cargar en base a la salida de un método de acción.

•  Para cualquier página dada, una regla de navegación define qué salidas se pueden dar y qué páginas se deben cargar en base a esas salidas.

•  La correspondencia entre una salida y una página se llama caso de navegación (navigation case).

61

•  Las reglas de navegación se expresan en el fichero de configuración (faces-config.xml)

<navigation-rule>

<from-view-id>/login.jsp</from-view-id>

<navigation-case>

<from-outcome>success</from-outcome>

<to-view-id>/mainmenu.jsp</to-view-id>

</navigation-case>

<navigation-case>

<from-outcome>failure</from-outcome>

<to-view-id>/login.jsp</to-view-id>

</navigation-case>

</navigation-rule>

62

Ciclo de vida

•  Para entender cómo el framework enmascara la naturaleza del procesamiento de la petición subyacente del API Servlet, es de gran ayuda analizar cómo JSF procesa cada petición.

•  El ciclo de vida de una página JSF es similar al de una página JSP: el cliente hace una petición HTTP de la página y el servidor responde con la página traducida a HTML

•  JSF proporciona algunos servicios adicionales mediante la ejecución de algunos pasos extras

63

•  Este proceso comienza tan pronto como se recibe una petición por el servlet JSF

•  Hay seis fases primarias (mostradas en los cuadrados sombreados), y después de la mayoría de ellas se procesan eventos (mostrados en cuadros blancos).

64

•  Restore View •  JSF construye el árbol de componentes de la página

JavaServer Faces, conecta los manejadores de eventos y los validadores y graba el estado en el FacesContext

•  Apply Request Values •  Una vez construido el árbol de componentes, cada

componente del árbol extrae su nuevo valor desde los parámetros de la petición con su método decode. Su valor se almacena localmente en el componente.

•  Process Validations •  JSF procesa todas las validaciones registradas con los

componentes del árbol

65

•  Update Model Values

•  Una vez que JSF determina que el dato es válido, puede pasar por el árbol de componentes y configurar los valores del objeto de modelo correspondiente con los valores locales de los componentes

•  Invoke Application

•  JSF maneja cualquier evento a nivel de aplicación, como enviar un formulario o enlazar a otra página

•  Render Response

•  JSF invoca las propiedades de codificación de los componentes y dibuja los componentes del árbol de componentes grabado en el FacesContext.

66

Ficheros de configuración

•  En web.xml <web-app>

<display-name>Tienda</display-name>

<description>Comprar un ordenador</description> <!-- Faces Servlet -->

<servlet> <servlet-name>Faces Servlet</servlet-name>

<servlet-class>javax.faces.webapp.FacesServlet </servlet-class> </servlet>

<!-- Faces Servlet Mapping --> <servlet-mapping>

<servlet-name>Faces Servlet</servlet-name> <url-pattern>/faces/*</url-pattern>

</servlet-mapping> </web-app> •  Tambien mapping a ‘*.jsf’ y ‘*.faces’

67

•  En faces-config.xml

68

69

•  Destacar el uso frecuente de:

<application>

<message-bundle>tiendadecoches.bundles.Messages</message-bundle>

<locale-config>

<default-locale>es</default-locale>

<supported-locale>en</supported-locale>

</locale-config>

</application>

…

<converter>

<description>Registra la implementación Converter concreta, tiendadecoches.CreditCardConverter utilizando el identificador creditcard.

</description>

<converter-id>creditcard</converter-id>

<converter-class>tiendadecoches.CreditCardConverter</converter-class>

</converter>

70

<managed-bean>

<description> Para inicializar en la sesión el bean del usuario que utiliza la aplicación

</description>

<managed-bean-name>usuario</managed-bean-name>

<managed-bean-class> ejemplo.JDBCUsuarioDAO

</managedbean-class>

<managed-bean-scope>session</managed-bean-scope> …

<navigation-rule>

<from-view-id>/login.jsp</from-view-id>

<navigation-case>

<description> Cualquier acción que retorna validado en login.jsp debería navegar a menu.jspx </description>

<from-outcome>validado</from-outcome>

<to-view-id>/menu.jspx</to-view-id>

</navigation-case>

<navigation-case>

<description> Cualquier acción que retorna fallo en login.jsp debería navegar a errorEntrada.jsp </description>

<from-outcome>fallo</from-outcome>

<to-view-id>/errorEntrada.jsp</to-view-id>

</navigation-case> …