06. JSF (Java Server Faces)

JSF (Java Server Faces)

Actualmente la mayoría de las aplicaciones se distribuyen por Internet.

Casi todos los accesos clientes se hacen a través de Web.

Cada vez hay mas clientes específicos con dispositivos y pantallas diferentes.

El modelo de programación Web actual está basado en documentos no basados en pantallas de interacción.

Introducción

JSF logra la unión entre los cliente Web actuales y el modelo tradicional de componentes.

Logra separar la renderización del componente.

Logra desplazar la interacción del usuario con el programa al modelo tradicional de eventos.

JSF es la evolución estándar de Struts, por los mismos que realizaron Struts.

Es un estándar claro y potente para poder hacer aplicaciones visuales mas potentes.

Aportaciones de JSF

Nos da Renderización, árbol de componentes visuales, validadores, conversores y eventos y javabeans.

Nos aporta un ciclo de vida claro estándar. Nos permite configurar y definir

externamente el flujo de pantallas, la navegación.

Nos permite modificar o incorporar componentes básicos propios en la arquitectura.◦ Por ejemplo un ciclo de vida propio

Arquitectura

Aporta tags para funcionar sobre jsps. Se podría usar JSF en otros entornos diferentes a

jsp. Tenemos una librería estándar de JSF-Html para

crear aplicaciones web. Nos da un nivel de información independiente

de estar en un contenedor web-servlets o un contenedor basado en portlets.

Retrasa la renderización hasta el último momento para poder renderizar con toda la información bien preparada.

Nos permite crear componentes propios para reutilizar.

JSF tiene un Servlet como entrada de las llamadas a su arquitectura.

Relación entre JSF y JSP

Se necesita configurar un servlet de JSF para enlazar con el contenedor Web.

Se basa en un fichero de configuración, por defecto faces-config.xml

¿Qué gestionamos en el faces-config?◦ Componentes (Edit/ Label/ ComboBox).◦ Validadores.◦ Conversores.◦ Beans (Java Beans).◦ Navegación ◦ Aspectos avanzados...

Elementos

Debemos registrar el servlet.◦ javaxfaces.webapp.FacesServlet

Tenemos que hacer el servlet-mapping de las uris que vamos a tratar con JSF.◦ Normalmente de tipo

/facesl* *.faces *.jsf

Configurando JSF:Descriptor web.xml

Se pueden configurar los siguientes parámetros globales (context-param):◦ javax.faces.CONFIG_FILES indicando una lista relativa

a nuestro contexto donde están los archivos de configuración de JSF. Por defecto carga /WEB-lNF/faces-config.xml.

◦ javax.faces.DEFAULT_SUFFIX indica el sufijo por defecto de recursos conteniendo componentes JSF, por defecto . jsp.

◦ javax.faces.LIFECYCLE_lD instancia de LifeCycle a usar por JSF por defecto LifecycleFactory.DEFAULT_LIFECYCLE.

◦ javax.faces.STATE_SAVING_METHOD La localización donde se va a guardar la información de estado: server o client. Por defecto server en el HttpSession

Parámetros de Configuración

La etiqueta principal es <faces-config>. Podemos tener mas de un archivo de

configuración. Podemos configurar:

◦ Java beans.◦ Registrar validadores propios.◦ Registrar conversores propios.◦ Configurar reglas de navegación.◦ Registrar Renders.◦ Registrar componentes propios.

El cerebro de la bestia:Faces-config.xml

Partimos de piloto 0.0, entorno de trabajo basado en Maven2 y generado mediante el arquetipo para MyFaces.

Lo modificamos para que:◦ Aparezca una nueva página welcome.jsp con un

mensaje de “Hola Mundo”◦ Index.jsp redirija mediante

response.sendRedirect(...) a welcome.jsf ¿? Probamos la aplicación. ¿Qué ha ocurrido?

Taller práctico – Hola Mundo con Java Server Faces

Welcome.jsf no es aún una vista válida JSF. En JSF todas las vistas deben estar

contenidas en un elemento f:view:<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

<f:view>

...

</f:view>

¿Por qué? Encapsular la JSF en el componente vista.

Taller práctico – Primera Vista JSF

Permite declarar los beans que van a ir instanciando automáticamente y en el scope que se van a a encontrar.

Configurar propiedades de los beans. Poner el valor de una propiedad de un bean al

resultado de la evaluación de un método value-binding.

Scopes:◦ request.◦ Session.◦ application.◦ none.

El bean es inicializado cada vez que es referenciada y no se guarda en ningún scope.

Configuración de Beans

<managed-bean> <managed-bean-name>NA</managed-bean-name> <managed-bean-class>model.ImageArea</managed -bean-class> <managed-bean-scope>application</managed-bean-scope> <managed-property>

<property-name>shape</property-name> <value>poly</value>

</managed-property> ……………………..…………………………</managed-bean-name>

</managed-bean>

Ejemplo de Declaración de Bean

Vamos a inyectar nuestro primer bean en JSF:◦ En primer lugar, creamos la clase

es.uniovi.si.UsuarioBean con una propiedad nombre

◦ Lo declaramos en el faces-config.xml como bean usuario, inicializando su propiedad nombre con la cadena “Invitado”.

<managed-bean>

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

<managed-bean-class>es.uniovi.si.UsuarioBean</managed-bean-class>

<managed-property>

<property-name>nombre</property-name>

<value>invitado</value>

</managed-property>

</managed-bean>

Taller práctico: Mi primer Bean en JSF

Creamos una nueva vista entrada.jsp y, dentro, mostramos la propiedad nombre del bean usuario mediante el componente de salida:

Hola <h:outputText value="#{usuario.nombre}"/>, bienvenido a mi sitio web.<br>

Probar a acceder mediante piloto/entrada.jsf ¿Funciona?

Acceder ahora mediante piloto/entrada.jsp ¿Y ahora?

Quitar ahora f:view y probar con entrada.jsf. ¿Funciona?

Resuelto en piloto 1.0.

Taller práctico: Mi primer Bean en JSF

Realiza una acción al ser activado. Propiedades básicas:

◦ Action String o method-binding al método que devuelve ese String. EL String es usado por el NavigationHandier para determinar la pagina siguiente de acceso.

◦ actionListener para escuchar los eventos de acción

Botones: UICommand

Dos tipos de etiquetas básicas◦ commanButton representa un botón

<h:commandButton ../> ◦ commandLink representa un elemento de acción

en formato link (con <a></a>) . La etiqueta ha de contener una etiqueta outputText

para representar donde el usuario clickea para generar el evento

UICommand

Representa los campos de entrada. En el renderizador de Html tenemos varios tags

◦ inputHidden representa un campo hidden◦ inputSecret representa a un campo password◦ inputText◦ inputTextArea

Suelen tener asociados elementos en las siguientes propiedades◦ Converter Identifica el conversor de datos a utilizar.◦ Validatos method-binding a la validación.◦ valueChangeListener method-binding para escuchar los

cambios de valor

UInput

Cuando apliquemos JSF, tenemos que ceñirnos a sus reglas y utilizar sus etiquetas en lugar de las etiquetas estándar HTML.

Éstas implementan más lógica por detrás que nosotros no vemos pero que nos ahorra trabajo.

Ejemplo de formulario en JSF:<h:form><h:inputText value="#{usuario.login}"/><h:commandButton value="Login" action=“¿?"/></h:form>

Formularios en JSF

Editamos welcome.jsp y añadimos lo siguiente:

<h:form><h:inputText value="#{usuario.nombre}"/><h:commandButton value="Enviar" action=“entrada.jsf"/>

</h:form>

Accedemos a la aplicación y pulsamos el botón... ¿Qué ocurre?

Examinamos el código fuente. ¿Adonde apunta el formulario? ¿Por qué?

Taller práctico: Mi primer formulario

En JSF, TODAS las peticiones van a la propia página. Entonces. ¿Dónde está el truco?

El servlet mapping hace que el controlador caputure TODAS las peticiones que concuerden con la extensión *.jsf

Lo que debemos poner en el campo action de un componente de comando (nótese que no es a nivel de formulario) es la acción que se desea disparar

¿Cómo se navega entonces? Estableciendo el mapa de navegación en el controlador.

¿Adónde va mi request?

Permite configurar cual será la siguiente pagina después de pulsar un boton o link.

Cada regla define como navegar desde una página hacia otro conjunto de páginas.

La siguiente pagina depende del método action sobre el que se haya pinchado y la salida lógica que de la etiqueta referenciada.

Salidas típicas: ◦ success:

todo ocurrió correctamente.◦ Failure:

hubo algo mal, ir a una página de error.◦ Logon:

el usuario necesita logearse primero, IR a pagina de logon◦ No result:

la búsqueda no encontró nada. Ir a la pagina de búsqueda de nuevo

Navegación

From-view-id ◦ Indica la página origen de la request.

From-action◦ indica el action del que procede y que da su valor.

From-outcome◦ Representa el evento que dispara la transición.

To-view-id ◦ indica el id de la vista a la que pasamos

Elementos de Navegación

<navigation-rule> <from-view-id>/logonjsp</from-view-id> <navigation-case>

<from-action>#{LogonForm.logon}</from-action>

<from-outcome>success</from-outcome> <to-view-id>/storefrontjsp</to-view-id>

</navigation-case> <navigation-case>

<from-action>#{LogonForm.logon}</from-action>

<from-outcome>failure</from-outcome> <to-view-id>/logon.jsp</to-view-id>

</navigation-case> </navigation-rue>

Ejemplo: Navegación

Vamos a establecer una regla de navegación en el faces-config.xml que determine que cuando se dispara la acción login desde la página welcome.jsp el controlador nos debe redirigir a entrada.jsf:

<navigation-rule><from-view-id>/welcome.jsp</from-view-id><navigation-case>

<from-outcome>login</from-outcome><to-view-id>/entrada.jsf</to-view-id>

</navigation-case></navigation-rule> Recordad modificar el formulario para que

ejecute la acción login. ¿Funciona?

Taller práctico: Enlazando páginas

Problema: El bean aparece siempre con el mismo valor. ¿Por qué?:

El scope por defecto de los beans es page, y nosotros no hemos establecido ninguno diferente. Editar el faces-config.xml y forzar que el bean-scope sea request.

Volver a probar la aplicación.Resuelto en piloto 2.0

Taller práctico: Enlazando páginas

Con #{expresion languaje} podemos referirnos a los métodos, propiedades y elementos <managed-bean>

<managed-bean-name>customer</managed-bean-name> <managed-bean-class>CustomerBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property>

<property-name>areaCode</property-name> <value>#{initParam.defaultAreaCode}</value>

</managed-property> …………….

</managed-bean>

Más de beans...Bean con Binding

Es un Map de Collections, se puede especificar la clase que hace de llave <managed-bean> <managed-property> <property-name>prices</property-name> <map-entries> <map-entry>

<key>My Early Years: Growing Up *7</key> <value>30.75</value>

</map-entry> <map-entry>

<key>Web Servers for Fun and Profit</key>

<value>40.75</value> </map-entry> </map-entries> </managed-property>

</managed-bean>

Inicialización de una Bean con un Map

<managed-bean> …….

<managed-property> <property-name>books</property-name> < list-entries > <value-class>java.lang.String</value-class>

<value>Web Servers for Fun and Profit</value> <value>#{myBooks. bookld [3]}</value> <null-value/> </ list-entries >

</managed-property>

</managed-bean>

Arrays y Listas de Propiedades

¿Cómo hacemos que nuestras vistas interactúen con el modelo?

Sabemos como forzar a que JSF invoque un método get o set sobre un bean, luego ¿Implementando lógica en los accessors? No, sería desnaturalizar el método.

Alternativa: Navegación dinámica

Interactuando con el modelo

En el ejemplo que hemos visto, el botón de commando dispara una acción que, tal y como hemos configurado, nos redirige de terminantemente a otra vista.

En las aplicaciones reales, la redirección dependerá del resultado de la interacción con el modelo. Ejemplo hago login y:◦ Si es correcto, paso a la página de entrada◦ Si no, vuelvo a la página de login y muestro un error.

Para esto necesito:◦ Elementos donde implementar la lógica decide la

navegación◦ La posibilidad de establecer las diferentes transiciones en

base al resultado.

Navegación dinámica

Para implementar navegación dinámica, debemos utilizar en el elemento de comando que hace submit una expresión de método.

Ejemplo:<h:commandButton label="Login" action="#{loginController.verifyUser}"/>

En este caso, al pulsar el botón se invocará el método verifyUser del bean dado de alta como loginController.


¿Cómo se determina el destino tras ejecutar un método de bean?

Desde el bean:if (...)

return "success";

else

return “login-error";

El bean dispara acciones en base a las cuales se determinará cual será la siguiente vista.


<navigation-rule><navigation-case>

<from-action>#{loginController.verifyUser}</from-action>

<from-outcome>success</from-outcome><to-view-id>/consultaLibros.faces</to-view-

id></navigation-case><navigation-case>

<from-action>#{loginController.verifyUser}</from-action>

<from-outcome>login-error</from-outcome><to-view-id>/login.faces</to-view-id>

</navigation-case></navigation-rule>


Vamos a implementar e inyectar un bean que se encarge de nuestro futuro proceso de login. Para eso:◦ Añadimos una propiedad password al bean

usuario y completamos el formulario de la página welcome para que se recoja la contraseña.

◦ Creamos es.uniovi.si.LoginAction tal que: Contenga una propiedad de tipo UsuarioBean Tenga un método login que:

Si usuario=contraseña=admin entonces dispare “success”

Si no, dispare login-error.

◦ Establecemos la navegación en el faces-config.xml

◦ ¿Funciona? ¿Qué ocurre?

Taller práctico: Preparando el login

<managed-bean> <managed-bean-name>customer</managed-bean-name> <managed-bean-class>com .mycompany.mybeans.CustomerBean</managed-bean-class> <managed-bean-scope> request </managed-bean-scope> <managed-property>

<property-name>mailingAddress</property-name> <value>#{addressBean}</value>

</managed-property> <managed-property>

<property-name>streetAddress</propertyname> <value>#{addressBean}</value>

</managed-property> <managed-property>

<property-name>custom erType</property-name> <value>New</value>

</managed-property> </managed-bean> <managed-bean> <managed-bean-name>addressBean</managed-bean-name> <managed-bean-class>com .mycompany.mybeans.AddressBean</managed-bean-class> <managed-bean-scope> none </managed-bean-scope> <managed-property>

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

<managed-property> </managed-bean>

Beans Asociados – Más inyección de dependencias

Inyectar el bean usuario en el bean loginAction en el faces-config.xml

Probar la aplicación.Resuelto en piloto 3.0

Taller práctico – Terminando mi Login

Modificar la versión anterior para añadir un contador que, basándose en el contexto de la aplicación, cuente cuantos logins se realizan en la aplicación contando todos los de los usuarios.

¿Desde donde lo hacemos? ¿En qué clase lo inyectamos?

Visualizar el resultado del contador en la página final.

Taller práctico

Hasta ahora hemos visto y usado algunos de los elementos que nos aporta JSF, como los formularios, los comandos, etc.

Los elementos de JSF se clasifican en:◦ Componentes JSP◦ Objetos Implícitos

Visión global: ¿Qué nos trae JSF?

JSF basa sus vistas en un árbol de nodos visuales.

Los nodos tienen asociados un renderizador que crea su visualización.

Entre llamada y llamada se recrea el árbol de objetos en el lado servidor.

Hay un conjunto estándar de componentes base.

Tenemos una implementación de HTML que implementa de diversa manera estos componentes base.

Vamos a ver los componentes base con su reflejo sobre los componentes Html.

Componentes JSP

Podemos usar el EL para asociar métodos y propiedades a los elementos #{.. .}.

Con el Expresion Languaje de JSF tenemos una serie de objetos implícitos en el contenedor web estándar:◦ applicationScope◦ cookie◦ facesContext◦ header◦ headerValues◦ initParam.◦ param◦ paramValues◦ requestScope◦ sessionScope◦ view

Indica el UIComponent que es raíz del árbol para esta llamada

EL Objetos Implícitos

Los componentes han de tener un constructor vacío para poder instanciarse.

Todo componente visual tiene una representación como objeto en el servidor en una jerarquía nodal.

El renderizador se encargara de generar su representación visual según convenga.

Elementos Visuales

El paquete visual principal es javax.facescomponent.

Todo elemento visual forma parte de un árbol nodal de elementos.

El elemento base de la jerarquía es UIComponent. El elemento funcional base que hereda de

UIComponent es UIComponentBase. El elemento raíz de un árbol es UIViewRoot. Todo componente debe especificar constantes

indicando el tipo bajo el cual el componente es registrado y la familia para seleccionar el render adecuado.◦ COMPONENT_TYPE, Component_FAMILY

Elementos Visuales

Propiedades nodales◦ getParent.◦ getChildren.◦ getChildrenCount.◦ getViewNode

Nos permite acceder al nodo principal del árbol

◦ Buscar componentes hijo.◦ Cada componente tiene un Id, bien impuesto o

bien generado.

Propiedades del UIComponent

Nos permite acceder al FacesContext al que pertenece el componente.

Todo componente pertenece a una familia y un renderType, la conjunción de ambos determina el render a utilizar.

Casi cada componente UI va a tener una etiqueta asociada.◦ getAttibutes nos permite acceder a las

propiedades y atributos del componente

Propiedades del UIComponent

Al crear componentes tenemos que implementar la codificación y decodificación de la información.

Decode:◦ Leemos el dato del request y propagamos su valor.

Encode:◦ EncodeBegin◦ EncodeChildren◦ EncodeEnd◦ Durante la fase de renderización los datos se pasan al lenguaje

de marcado.◦ En caso de no necesitar tener en cuenta los componentes hijo

solo implementaremos en encodeEnd.

Codificación de datos

Es el nodo raíz de un árbol de componentes visuales.

Nos permite poner el locale del árbol. Hereda de UIBaseComponent. Tiene asociado un RenderKit:

◦ Es una familia de renders.◦ Cada render en el RenderKit esta designado por

tipo y familia que renderiza.◦ Su etiqueta es f:view y su único atributo

opcional es locale

UIView

Actualmente hay dos librerías de etiquetas básicas:

<%@ taglib uri=http://java.sun.com/jsf/core prefix=”f” %><%@ taglib uri= uri=http://java.sun.com/jsf/html prefix=”h” %>

Librerías de etiquetas

Los componentes han de estar metidos dentro del un único nodo raiz <f:view>

Cuando se realiza un <jsp:import> o <c:include> todos elementos incorporadas han de meterse en un <f: subview>◦ <f:subview>

<c:include ...>◦ </f:subview>

Cualquier texto de plantilla incluido por el include o el import, actualmente debe meterse dentro de una etiqueta <f: verbatim>

Cada elemento va a tener los atributos del componente mas los añadidos por el render.◦ Con el render de HTML podemos ver que el Componente UIData

tiene una implementaron (por extensión) HTMLDataTable que contiene los atributos configurables relativos a Html y específicos del Render

Librería de Etiquetas

Propiedades usuales:◦ Id del componente, si no se lo ponemos es generado

automáticamente.◦ lmmediate: si esta a true indica que los eventos,

validaciones y conversiones se realizan en la fase de apply request en vez de en una fase posterior.

◦ Rendered indica si el componente ha de ser renderizado.◦ Style especifica el cascading style sheet para la etiqueta.◦ styleClass especifica el class del CSS (cascading style

sheet).◦ Value indica el valor del componente, como literal o

enlazado con una propiedad del modelo de información.◦ Binding identifica una propiedad de un bean y asocia la

instancia UI del componente a esa propiedad (set.. .(UI.. A)).

◦ Todos los atributos excepto id y var permiten la asociación de value-binding con el Expresion Lenguaje de Java Server Faces. #{objeto.propiedad}

Etiquetas Html

Representa un form de entrada. Engloba a todos los componentes que

muestran o recogen información.◦ <h:form>. ..</h:form>

UIForm

Representa una tabla de información. <h:dataTable..>... Tiene UIColumns dentro. Soporta estar enlazado con una colección

de objetos sobre la que itera. El atributo value indica la colección sobre

la que iterar. El atributo var indica la variable sobre la

que se va a ir guardando el objeto de datos en cada iteración.

UIData

Tipos de datos soportados:◦ Listas y arrays de beans.◦ Una sóla bean.◦ Un javax.sql.ResultSet y

javax.servlet.jsp.jstl.sql.ResultSet.◦ javax.sql.RowSet.◦ Javaxfaces.model.DataModel

Todos los tipos de datos soportados tienen un Wrapper a DataModel, la implementación encapsula nuestro objeto en el wrapper correspondiente.

UIData

First indica la primera fila a ser mostrada. Rows indica el número de filas a mostrar. Existen varias propiedades que pueden indicar

listas de estilos para los diferentes elementos:◦ columnClasses◦ footerClass◦ headerClass◦ rowClass◦ StyleClass

Propiedades de UIData

Representa una columna de información en un UIData

Cada columna puede tener uno o varios facet que indicarían las cabeceras y pies de las columnas◦ Si se quiere poner mas de un componente dentro de una

facet se ha de usar un panelgroup para embeberlos ya que facet solo soporta tener un componente hijo.

◦ Un facet se usa para representar un componente que es independiente de la relación padre-hijo en el árbol de elementos.

◦ En el caso de las columnas las cabeceras y pies sólo se pintan una vez, no en cada bucle.

<h:column>

UIColumn y los facets

<h:dataTable value="#{gestionLibrosService.libros}" var="libro">

<h:column>

<f:facet name="header">

<h:outputText value="Título" />

</f:facet>

<h:outputText value="#{libro.titulo}"/>

</h:column>

<h:column>

<f:facet name="header">

<h:outputText value="Autor" />

</f:facet>

<h:outputText value="#{libro.autor}"/>

...

</h:dataTable>

Ejemplo de uso

Modificar la versión 3.0 del piloto y:◦ Crear una clase LibroBean con las propiedades

autor, título, descripción y precio.◦ Crear una clase Libreria que contenga un Vector

de LibroBeans almacenados en una propiedad catalogo

◦ Declarar una librería con al menos 3 libros diferentes y denominarla liberia

◦ Modificar la página entrada.jsp para que muestre el catálogo de la librería usando un tag h:dataTable.

¿Qué scope tendrán que tener los libros? ¿Y la librería?

Resuelto en piloto 4.0

Taller práctico: Uso del DataTable

Cada llamada que lleva a un JSF tree pasa por una serie de fases determinadas que crean su ciclo de vida.

Existen tres tipos de escenarios posibles:◦ Una petición sin JSF genera una respuesta con JSF.◦ Una petición con JSF genera un respuesta con JSF.◦ Una petición con JSF genera una respuesta sin JSF.

A su vez la aplicación también puede recibir peticiones sin JSF que generen respuestas sin JSF

Ciclo de Vida de JSF

Toda llamada o request tiene asociado un FaceContext y al hilo de llamada.

El FaceContext solo debe existir durante la request hasta que se llame a su método release.

No se le debe referenciar por un objeto que tenga una vida mas larga que la request .

Contiene toda la información relativa al estado en la request y la renderización de la respuesta.

Encapsula el elemento raíz visual ViewRoot.

FaceContext

Encapsula los posibles mensajes. Nos permite acceder al Singleton de Application. Encapsula ResponseWriter -salida de

cáracteres- y ResponseStream —salida binaria-. Como flujos de escritura para los renderizadores.

Nos permite acceder a ExternalContext:◦ Nos da acceso al entorno independientemente de estar

en un contenedor de servlets o de portlets.◦ Accedemos a todo el entorno de información que

tendríamos como servlet.

FaceContext

Fases Estándar

Restore View

El servidor recibe una llamada y recompone los objetos de la vista en el servidor.

Examina si FacesContext tiene un UIViewRoot en caso de tenerlo:◦ Le asigna el locale correspondiente

(internacionalización).◦ Para cada valor en el árbol mira si tiene un valuebinding

asociado a binding y si lo tiene llama a setValue() pasando la instancia en donde se encontró.

◦ No se realizan mas acciones. Se crea el viewID de la URI y de los valores de prefijo:

◦ ViewHandler.DEFAULT_SUFFIX_NAME

Restore View

Llaman a viewHandler.restoreView() pasando la instancia FacesContext asociada a la llamada y el viewID, consiguiendo el UIViewRoot como respuesta:◦ En caso de devolver null no había vista asociada por lo

que se crea una y se pasa al renderResponse: se llama a ViewHandler.createView() y a

FacesContext .renderResponse()◦ Si la petición no contiene parámetros de llamada ni datos

en POST se llama a renderResponse

Restore View

Se almacena el UIViewRoot en el FacesContext.

Se determina el valuebinding para cada atributo binding y se llama al setValue.

Al final de esta fase tenemos recuperado el viewRoot que había y si acaso se ha creado uno nuevo.

Restore View

Apply Request Values

Da la oportunidad a los componentes a actualizar sus valores a los valores que llegan de la request.

Se llama al método processDecodes() de todos los componentes del árbol UIViewRoot.

Los componentes que implementan ActionSource que reconocen que fueron activados encolan su evento.◦ Estos eventos son notificados al final de esta

fase


Los componentes que implementan EditableValueHolder que tienen la propiedad immediate a true realizan la conversión y validación. lncluyendo el potencial lanzamiento del evento ValueChange.

◦ Normalmente immediate esta a false esto ocurre posteriormente en la fase de Process Validations


Todo error producirá un mensaje que se encolara en el FaceContext, y el componente que la lanza será marcado como invalido.

En cualquier momento si nuestra lógica en los decode, o en los eventos llama a responseComplete en FacesContext. Se termina inmediatamente el procesado del request.

Si se llama a renderResponse en el FacesContext se transfiere el control a la fase de Render Response.

En caso contrario pasamos a la fase de Process Validations

Posibilidades de cambio de Fase

Process Validations

Se procesan las validaciones llamando a processValidators.

Cualquier fallo en la validación mete un mensaje de error en el FacesContext.◦ Y la propiedad valid del componente se pone a

false. En cualquier validador puede llamar a

responseComplete o a renderResponse de FacesContext.

Process Validations

Update Model Values

Llegados a esta fase se asume que los contenidos son sintácticamente y semánticamente correctos.

Se asume que el valor local de los componentes ha sido actualizado.

Es el momento de actualizar los datos del modelo de la aplicación.

Esto se produce recursivamente llamando a UlComponent.processUpdates.

La actualización dentro de un componente se realiza llamando al método updateModel.

Update Model Values

Durante la actualización los eventos son encolados hasta la finalización de la fase donde se procesan.

Al finalizar esta fase los valores del modelo de datos han sido actualizados y los valores de los componentes han sido vaciados.

Cualquiera de nuestros métodos podría llamar a responseComplete o a renderResponse.

Update Model Values

Invoke Application

Si se alcanza esta fase se asume que la actualización del modelo ha sido completada.

Se llama al método processApplication de UIViewRoot.

Se llama a todos los eventos encolados con phaseId.INVOKE_APPLICATION.

Excepcionalmente se podría llegar a cambiar el actionListener por defecto con setActionListener

Invoke Application

Render Response

Hace que la respuesta sea renderizada al cliente.

Hace que el estado de la respuesta sea guardado para ser procesado en llamadas sucesivas.

Cuando un componente de árbol es seleccionado para renderizarse se llama a su método de encodexxx().

Para los elementos que implementan ValueHolder se ha de producir su conversión.

Antes de completarse el estado de la vista ha de ser guardado usando los métodos de la clase StateManager.◦ Esta información ha de estar disponible para que Restore

View pueda acceder a ella en sucesivas llamadas.

Render Response

Son beans que no responden a entidades, sino a agrupaciones que datos que por motivos prácticos, nos puede interesar procesar juntos, a nivel no de valores sino de componentes.

Es imprescindible para validaciones en las que se han de comprobar relaciones entre componentes.

Ejemplo: Representación de formularios

Backing beans

Si queremos hacer un backing bean para un formulario de cambio de usuario en sesión que muestra y recibe información al mismo tiempo, por ejemplo:

Public class ChangeSessionForm

{

UIInput newUser;

UIOutput oldUser;

//getters and setters...

}

...

En la JSP:<h:outputText binding="#{changeSessionForm.oldUser}"/>

Lo que le pasa JSF al formulario al hacer binding no es el valor del componente, sino su referencia.

Backing beans

Vamos a alterar el proceso de login para utilizar es.uniovi.si.backing.LoginForm como backing bean. Para ello:◦ Declaramos dos propiedades UIInput (login y

password)◦ Declaramos el bean como loginForm y se lo

inyectamos al LoginAction◦ Hacemos el enlazado entre los campos del

formulario y modificamos adecuadamente la clase LoginAction para que partir de ahora recupere los valores del formulario.


Taller práctico: Uso de backing beans

Los elementos de formulario que muestran elementos entre los que seleccionar (combo, radio, listas, etc) comparten modo de funcionamiento.

La entrada de datos debe ser una colección de elementos SelectItem.

Ej:◦ New SelectItem(“010”,”The Matrix”);

¿Cómo se conecta con el formulario?

Más elementos UIInput...

Etiqueta h:selectBooleanCheckbox Representa un estado booleano

UISelectBoolean

Tres renderizaciones básicas◦selectManycheckbox

Muestra una lista de checkboxes Value indica el set de elementos seleccionados

actualmente. Layout indica como se han de poner los checkbox

pageDirection/lineDirection. Contiene etiquetas selectItem o selectItems

representando a los elementos.◦selectManyListBox◦selectManyMenu

UISelectMany

Permite seleccionar solo un elemento:◦ selectOneRadio◦ selectOneMenu◦ selectOneListbox

Su contenido son colecciones de Selectltem o Selectltems

UISelectOne

Nos permiten anidar elementos en los select f:SelectItem Un UISelectItems representa a una colección de

SelectItem o de SelectItemGroup. SelectItems permite tomar los datos de Arrays,

Map y Collection de elementos tipo SelectItem o SelectItemGroup◦ Javax.faces.modelSelectItem.◦ Todo Item tiene un Label y un value.

UISelectItems UISelectItem, UISelectGroup

Ej: para cargar un combo...◦ Bean pruebaForm:

Private UIInput propiedadDestino;

public Collection getOpciones()

{

opciones = new ArrayList();

opciones SelectItem(“01”,“Opción 1"));

opciones SelectItem(“02",“Opción 2"));

return opciones;

}

◦ En la jsp:<h:selectOneMenu binding="#{pruebaForm.propiedadDestino}">

<f:selectItems value="#{pruebaForm.opciones}"/>

</h:selectOneMenu>

Carga de SelectItems.

Vamos a añadir al formulario de login un combo con el idioma preferido por el usuario. Para ello:◦ Añadimos una propiedad idioma de tipo IUInput al

LoginForm, y un método getIdiomas que retorne una colección de SelectItems con: “es”,”Español” “en”,”English”

◦ Lo enlazamos y mostramos lo recibido en el LoginForm al pulsar el botón.

(Resuelto en piloto 6.0)

Taller práctico: uso de combos

Completar piloto 6.0 para:◦ Añadir un formulario en entrada.jsp con:

Un combo donde se muestre la lista de libros Un editBox donde se introduzca la cantidad del libro

seleccionado◦ Un backing bean CarritoForm con un método add

para gestionar el carrito de la compra◦ Un CarritoBean que resida en sesión y que

encapsule una HashMap. Tendrá que tener un método public List<Entry> getProductos() que retorne una lista de objetos entry obtenidos mediante el método entrySet de la HashMap.

Taller práctico: Repasando

◦ Una página vercarrito que muestre el estado del carrito de la compra mediante una tabla, con un enlace a la página anterior:

<h:form>

<h:commandLink action="success">Volver</h:commandLink>

</h:form>


Taller práctico: Repasando

En cualquier aplicación es conveniente evitar tener las cadenas de texto hardcodeadas en el código fuente de las pantallas o páginas.

Los resource bundles sirven para seleccionar el mensaje de error en función de la clave, buscándolo en los resource bundle cargados. En el faces-config:

<application>

<resource-bundle>

<base-name>messages</base-name>

<var>msgs</var>

</resource-bundle>

</application>

Luego los referenciamos mediante EL. Ejemplo:<h:outputText value="#{msgs.welcome}"/>

El fichero messages.properties:welcome=Benvenido a mi página web!!!!

Resource Bundles y Mensajes

Sobre piloto 7.0... Creamos messages.properties. Lo configuramos como fichero de recursos

con el prefijo msgs. Extraer los mensajes de al menos una de

las vistas, por ejemplo, welcome.jsp. Probar la aplicación.


Taller práctico

JSF aprovecha la externalización de cadenas de texto para implementar la internacionalización de etiquetas.

En la request viaja el idioma preferido del navegador, representado por el parámetro LOCALE.

El locale responde a un código estandarizado (es,en,fr, etc).

Para internacionalizar la aplicación: un fichero de recursos por locale:◦ messages.properties◦ Messages_en.properties◦ Messages_fr.properties◦ ...

Internacionalización

Internacionalizar la aplicación para el inglés. Para ello:◦ Creamos un fichero messages_en.properties

copiando el messages.properties.◦ Traducimos las cadenas de texto al inglés◦ Para probarlo, establecemos en el navegador el

inglés como idioma por defecto.

Taller práctico

Actualmente se recomienda que el usuario pueda seleccionar explícitamente el idioma por encima de lo que diga el parámetro de idioma preferido del navegador.

JSF permite establecer el locale de varias formas diferentes:

Cambio del idioma del usuario

1. Estableciéndolo directamente en el faces-config.xml, el criterio idioma del navegador prevalece sobre ésto.:

<faces-config>

<application>

<locale-config>

<default-locale>en</default-locale>

<supported-locale>de</supported-locale>

</locale-config>

</application>

</faces-config>


2. Establecerlo como parámetro de la etiqueta f:view:

<f:view locale="de">

Ventaja, podemos establecerlo dinámicamente

<f:view locale="#{user.locale}"/>

3. Establecerlo por programaUIViewRoot object:

UIViewRoot viewRoot = FacesContext.getCurrentInstance().getViewRoot();

viewRoot.setLocale(new Locale("de"));


Modificar la aplicación para que el criterio del idioma que estamos seleccionando al hacer login cambie el locale de la aplicación.

Para verlo reflejado, internacionalizar alguna de las páginas posteriores al proceso de login.

¿Dónde recogemos el locale?Resuelto en piloto 9.0

Taller práctico

JSF aporta una colección de conversores predefinidos para tipos de datos estádar.

Converter es el interfaz capaz de hacer transformaciones string-objeto y objeto-string.◦ public java.langObject

getAsObject(javax.faces.context.FacesContext context, javax.faces.com ponent. UlComponent component, java.lang.String value)

◦ public java.Iang.String getAsString(javax.faces.context. FacesContext context, javax.faces.component. UlComponent component, java.lang.Object value)

Podemos asociar un conversor a un lnput/Output. El atributo converter indica la clase java que

implementa ese interface. También se puede anidar dentro de una etiqueta

con f:converter.◦ Su atributo converteride indica el id del conversor a usar.

Conversores

Tenemos conversores automáticos para los tipos básicos:◦ BigDecimalConverter◦ BigIntegerConverter◦ ByteConverter◦ CharacterConverter◦ DateTimeConverter◦ DoubleConverter◦ FloatConverter◦ IntegerConverter◦ LongConverter◦ NumberConverter◦ ShortConverter

Conversores Existentes

f:dateTimeConverter permite hacer conversiones de fecha:◦ datestyle: indica el formato: default, short, medium, long

y full.◦ locale: indica el Locale, por defecto

FacesContext.getLocale.◦ pattern: indica el patrón de fecha (dd/MM/yy por ejemplo)◦ timeStyle: define el formato de hora◦ timeZone: ◦ type: indica si el string va a contener una fecha, hora o

ambos

Conversor de Fecha

F:numberConverter permite controlar conversiones de numero◦ currencyCode, currencySymbol, pattern, locale,

minIntegerDigits, maxIntegerDigits, minFractionDigits, maxFractionDigits.

◦ groupingUsed: boolean indica si la cadena de salida tiene separadores de agrupamiento.

◦ integerOnly: boolean indica si se va a parsear la parte entera del valor.

◦ Type: indica si el valor a parsear y formatear es número, moneda o porcentaje

Conversor de número

El funcionamiento cuando hay un conversor es el siguiente:◦ El usuario envía los datos◦ Se vuelvan al árbol de componentes◦ Se invocan los conversores◦ En caso de error,

Se añaden los mensajes de error a la lista global de mensajes

Se vuelve a mostrar la página original y, en caso de que exista una etiqueta h:messages, se muestran los errores.

Conversores estándar

Ejemplos:<h:outputText value="#{payment.date}">

<f:convertDateTime/>

</h:outputText>

<h:outputText value="#{payment.amount}">

<f:convertNumber type="currency"/>

</h:outputText>

<h:inputText value="#{payment.amount}">

<f:convertNumber minFractionDigits="2"/>

</h:inputText>

Conversores estándar

¿Cómo muestro los errores de conversión/validación?

Si quiero mostrarlos todos juntos: <h:messages/>Si quiero mostrar los específicos de un

campo:<h:inputText id=“unidades" label=“Unidades" binding="#{bean.unidades}">

<f:convertNumber integerOnly="true"/>

</h:inputText>

<h:message for=“unidades"/>

Renderizado de errores

Basarse en el ejemplo anterior para aplicar un conversor para la cantidad de productos que se añaden al carrito y mostrar los errores asociados al cambo justo debajo del mismo.

Probarlo metiendo caracteres en el campo. ¿Funciona? ¿Cómo sale el mensaje?

Resuelto en piloto 10.0.

Taller práctico

Lo habitual será personalizar los mensajes de error que disparan los validadores, entre otras cosas, para internacionalizar la aplicación

Para ello, en los message-bundles sobrescribimos los mensajes predefinidos haciendo referencia a los códigos de identificación de cada mensaje.

Ejemplo:

Cambiando los mensajes predefinidos

Ejemplos:Código mensaje

javax.faces.converter.IntegerConverter. INTEGER

{2}: "{0}" must be a number consisting of one or more digits.

javax.faces.converter.IntegerConverter.INTEGER_detail

{2}: "{0}" must be a number between -2147483648 and 2147483647. Example: {1}

javax.faces.converter.DoubleConverter.DOUBLE

{2}: "{0}" must be a number consisting of one or more digits.

javax.faces.converter.DoubleConverter.DOUBLE_detail

{2}: "{0}" must be a number between 4.9E-324 and 1.7976931348623157E308.Example: {1}

javax.faces.converter.BooleanConverter.BOOLEAN_detail

{1}: "{0}" must be 'true' or 'false'. Any value other than 'true' will evaluate to

JSF permite validar el contenido de diferentes datos.

Podemos usar el atributo validator para apuntar al método de una bean que realiza validación.

Los validadores se pueden registrar en las clases que implementan EditableValueHolder.

En caso de no cumplirse la validación han de lanzar ValidatorException coteniendo un FacesMassage con el error.

Validadores

La clase DoubleRangeValidator con tag f:validateDoubleRange:◦ Valida un valor que puede ser convertido a coma flotante.◦ Mira que este entre dos valores dados, minimum-

maximum. La clase LengthValidator con tag f:validateLength.

Mira que la longitud de la cadena este entre un mínimo y un máximo

La clase LongRangeValidator con tag f:validateLongRange

Para valores que se puedan convertir a long. Mira que este entre dos valores dados.

Tres tipos de validadores estándar

Parámetros:

Validades predefinidos

Para comprobar que un dato está presente, no hace falta ningún validador anidado, basta con establecer el atributo required a true.

<h:inputText id="card" value="#{payment.card}" required="true”requiredMessage="#{msgs.campoRequerido}">

<f:validateLength minimum="13"/>

</h:inputText>

Taller prácticoModificar el piloto anterior para que además

se requiera el campo cantidad.

Validades predefinidos

Modificar la welcome.jsp para que:◦ Los campos login y password sean obligatorios.◦ La password tenga al menos 3 caracteres◦ Se visualicen mensajes personalizados e

internacionalizados. Resuelto en piloto11.0

Taller práctico

A partir del piloto anterior:◦ Definir un bean Usuarios (y declararlo como usuario)

que contenga un ArrayList con un UsuarioBean por cada usuario que queramos en la aplicación.

◦ Modificar el proceso de login para que el proceso se realice contra los usuarios del bean Usuarios.

◦ Crear una página registro.jsp y un backingbean RegistroForm con un método registro que reciba login y password y añada el nuevo usuario al bean usuarios.

◦ Enlazar desde welcome.jsp a registro.jsp con:<h:outputLink value="registro.jsf"> <f:verbatim>Nuevo usuario</f:verbatim>

</h:outputLink>Resuelto en piloto 12.0

Taller práctico: Juntándolo todo

En entornos de desarrollo de tipo cliente/servidor estamos acostumbrados a poder asociar eventos de tipo onClick o onChange a los componentes visuales de la pantalla.

En Web, dado que trabajamos sobre Http... ¿Se puede hacer esto?

JSF, al igual que otras plataformas como .NET simula esto encapsulando el evento en una request que es enviada al servidor sin llegar a disparar la acción del formulario.

Gestión de Eventos en JSF

JSF soporta tres tipos de eventos:◦ Value change events

Disparados por elementos UIInput cuando el valor que contienen cambia.

◦ Action events Los disparan los elementos UICommand cuando el

botón o enlace asociado es activado.◦ Phase Events

Son disparados rutinariamente por el ciclo de vida JSF.

Tipos de eventos en JSF

Pensados para elementos dependientes en los formularios. Ej: Combo de paises + combo provincias.

<h:selectOneMenu value="#{form.country}" onchange="submit()"

valueChangeListener="#{form.countryChanged}">

<f:selectItems value="#{form.countryNames}"/>

</h:selectOneMenu>

Esto dispara el método form.countryNames que se espera recibir un evento...

public void countryChanged(ValueChangeEvent event) {

FacesContext context = FacesContext.getCurrentInstance();

context.getViewRoot().setLocale(new Locale( (String) event.getNewValue()));

}

Value Change Events

Método Descripción

UIComponent getComponent()

Retorna una referencia al objeto que disparó el evento.

Object getNewValue() Retorna el nuevo valor

Object getOldValue() Retorna el valor antiguo

Los heredados de FacesEvent...

void queue() Encola el evento para que sea disparado al final del ciclo de vida actual

PhaseId getPhaseId() Devuelve el id de la fase en la que nos encontramos.

void setPhaseId(PhaseId) Marca el evento con el identificador de la fase en la que fue añadido a la cola.

El tipo ValueChangeEvent

Modificar el piloto para que el combo del idioma que se muestra en la página welcome tenga asociado un manejador de evento idiomaCambiado en loginForm de forma que cambie el idioma de la aplicación. Para ello:◦ Asociamos el evento al componente y al

manejador de evento en la jsp.◦ Implementamos el manejador en loginForm de

forma que establezca el nuevo idioma obteniendo la referencia al ViewRoot por medio de FacesConfig.


Taller práctico

Modificar entrada.jsp para que cuando cambie el combo del formulario, a su derecha se muestre el valor del libro seleccionado.

Para ello:◦ Asociamos el evento onValueChange a un método

productoSeleccionado del CarritoForm◦ Creamos un objeto UIOutput en la jsp que tome el

valor de un campo de tipo Integer del CarritoForm.


Taller práctico...

Son disparados por los objetos UICommand cuando se activa el componente

Se invocan durante la fase Invoke Application

<h:commandLink actionListener="#{bean.linkActivated}">

...

</h:commandLink>

Cuando se activa el componente, el formulario se envía y el controlador dispara los eventos.

Entonces... ¿En qué se diferencian de los actions?

Action Events

Actions: ◦ Diseñados para la lógica de negocio.◦ Deciden sobre la navegabilidad del sistema

Action listeners:◦ Orientados a ejecutar lógica de presentación.◦ No pueden decidir qué mensaje se envía al controlador.

Los dos tipos de elementos trabajan coordinadamente cuando el Action requiere información del interfaz de usuario.

Ejemplo: Una imagen enlazada que dependiendo de la zona pulsada, generará una redirección u otra.

Action listeners vs. Actions

Enlace en la JSP:<h:commandButton image="mountrushmore.jpg"

actionListener="#{rushmore.listen}"

action="#{rushmore.act}"/>

En el backing bean...private String outcome;

private Rectangle washingtonRect = new Rectangle(70,30,40,40);

private Rectangle jeffersonRect = new Rectangle(115,45,40,40);

public void listen(ActionEvent e) {


String clientId = e.getComponent().getClientId(context);

Map requestParams = context.getExternalContext().getRequestParameterMap();

int x = new Integer((String) requestParams.get(clientId + ".x")).intValue();

int y = new Integer((String) requestParams.get(clientId + ".y")).intValue();

outcome = null;

if (washingtonRect.contains(new Point(x,y)))

outcome = "washington";

...

Ejemplo de action events

public String act(){

return outcome;}

En primer lugar, creamos un nuevo método public void listen(ActionEvent e) en el CarritoForm que muestre un mensaje por pantalla demostrando que ha sido invocado.

Lo asociamos al botón de submit del formulario de la página entrada.jsp.

¿Cuál se dispara primero?

Taller práctico: Enlazando action events

Extender la versión anterior para:◦ Desligar al botón de submit del listener◦ Crear un enlace activo (h:commandLink) que:

no tenga atributo action Esté asociado al listener que hemos creado Se represente con la cadena de texto Incrementa

◦ Modificar el método listen para que cada vez que se ejecuta, además de mostrar el mensaje: Tome el string del UIInput cantidad Cree un entero y le sume uno Estableza de nuevo el valor calculado en el

componente cantidad.Resuelto en piloto 15.0

Taller práctico.

Hasta ahora hemos asociado los listeners por medio de los atributos de los elementos HTML.

Esto mismo se puede realizar utilizando dos etiquetas:◦ f:actionListener◦ f:valueChangeListener

Ventajas sobre la alternativa anterior: Puede asociar varios listeners diferentes al mismo elemento.

Event Listener Tags

Diferencias en la aplicación:◦ Versión con el atributo

<h:selectOneMenu value="#{form.country}" onchange="submit()"

valueChangeListener="#{form.countryChanged}">


</h:selectOneMenu>

◦ Versión con f:valueChangeListener:<h:selectOneMenu value="#{form.country}" onchange="submit()">

<f:valueChangeListener type="com.corejsf.CountryListener"/>


</h:selectOneMenu>

f:actionListener & f:valueChangeListener

No es una method expression sino

una clase!

La clase listener para los eventos de cambio de valor tiene que implementar una determinada interfaz: ValueChangeListener

public class CountryListener implements ValueChangeListener {

public void processValueChange(ValueChangeEvent event)

{

...

}

}

El controlador invoca el método processValueChange tras cada cambio.

Clase ValueChangeListener

Similar a la anterior:<f:actionListener type=" com.corejsf. RushmoreListener "/>

Y la clase, implementando la interfaz ActionListener:

public class RushmoreListener implements ActionListener {

public void processAction(ValueChangeEvent event)

{

...

}

}

Clase ActionListener

Crear una clase LibroCambiadoListener que implemente la interfaz ValueChangeListener

Implementar su método processValueChange para que saque un mensaje.

Asociarla a la etiqueta del combo de la págin entrada.jsp. Ojo! Hay que quitar el atributo que la liga al otro listener, son dos alternativas incompatibles!


Taller práctico

Problema: En casos como el combo de cambio de idioma, se nos están disparando los validadores que conviven dentro del mismo formulario. ¿Porqué?

Componentes inmediatos

Se disparan los validadores y conversores

Se procesan los eventos

Si marcamos un componente como inmediato:

<h:selectOneMenu binding="#{loginForm.idioma}" onchange="submit()” valueChangeListener="#{loginAction.idiomaCambiado}" immediate="true">


Problema:◦ El ciclo de vida sigue si rumbo normal tras la validación y

procesado de eventos de los componentes inmediatos Solución:

◦ Cortamos el flujo desde el listener y forzamos la renderización de la respuesta (el atajo en el gráfico anterior)

context.renderResponse();

Taller práctico Hacerlo sobre la versión actual del piloto para el cambio de

idioma en el login

¿Comandos inmediatos? En el caso de los comandos, también podemos hacerlos

inmediatos, pero no hacer falta forzar el renderizado porque al terminar van directos a dicha fase.


Supongamos que queremos hacer la internacionalización con dos banderas, una por idioma, haciendo que ambas sean commandLinks:

<h:commandLink action="#{localeChanger.englishAction}" immediate="true">

<h:graphicImage value="/british_flag.gif"/>

</h:commandLink>

En el servidor:public class ChangeLocaleBean {

public String germanAction() {


context.getViewRoot().setLocale(Locale.GERMAN);

return null;

}

public String englishAction() {


context.getViewRoot().setLocale(Locale.ENGLISH);

return null;

}

}

Envío de información desde la Interfaz de Usuario al Servidor.

Problema:◦ Estamos definiendo métodos que son

prácticamente iguales –repetimos lógica- y que en orientación a objetos podría ser uno solo parametrizado.

Solución:◦ Envío de información desde la interfaz al usuario.◦ Métodos:

f:param f:setPropertyActionListener f:attribute

Envío de información desde la Interfaz de Usuario al Servidor.

Nos permite adjuntarle un parámetro a un componente.

Se comporta diferentemente dependiendo del tipo de componente:◦ Si lo usamos en un h:outputText, los distintos

parámetros se usan para rellenar las variables ({0} is bigger than{1}) que se encuentren en el valor del componente.

◦ Si lo usamos en un UICommand, los parámetros se añaden como un parámetro de la request.

<f:param.../>

Para el ejemplo anterior:<h:commandLink immediate="true” action="#{localeChanger.changeLocale}">

<f:param name="languageCode" value="de"/>

<h:graphicImage value="/german_flag.gif" style="border: 0px"/>

</h:commandLink>

En el servidor:public String changeLocale() {


String languageCode = getLanguageCode(context);

context.getViewRoot().setLocale(new Locale(languageCode));

return null;

}

private String getLanguageCode(FacesContext context) {

Map<String,String> params=context.getExternalContext().getRequestParameterMap();

return params.get("languageCode");

}

<f:param...>

Crear en LoginForm un nuevo método idiomaCambiado() que recupere el parámetro nuevoIdioma de la request y establezca el nuevo Locale

Añadir dos etiquetas de comando, una por idioma, a la entrada.jsp, estableciendo como atributo action (no actionListener!) e inmediato = true;

Resuelto en trabajo 17.0

Taller práctico: uso de f:param

Similar, pero en lugar de añadirlo a la request, se añade como atributo al componente, por lo que tenemos que usar action listeners (reciben el componente en el evento!)

<h:commandLink immediate="true” actionListener="#{localeChanger.changeLocale}">

<f:attribute name="languageCode" value="de"/>


</h:commandLink>

En el servidorpublic void changeLocale(ActionEvent event) {

UIComponent component = event.getComponent();

String languageCode = getLanguageCode(component);

FacesContext.getCurrentInstance().getViewRoot().setLocale(new Locale(languageCode));

}

private String getLanguageCode(UIComponent component) {

Map<String, Object> attrs = component.getAttributes();

return (String) attrs.get("languageCode");

}

<f:attribute...>

Desde JSF 1.2, establece una propiedad directamente en nuestro backing bean...

<h:commandLink immediate="true” action="#{localeChanger.changeLocale}">

<f:setPropertyActionListener target="#{localeChanger.languageCode}” value="de"/>


</h:commandLink>

En el servidor...public class ChangeLocaleBean {

private String languageCode;

public String changeLocale() {


context.getViewRoot().setLocale(new Locale(languageCode));

return null;

}

public void setLanguageCode(String newValue) {

languageCode = newValue;

}

}

<f:setPropertyActionListener...

Otras cosillas...

<converter> <description>Converter for credit card numbers that normalizes the input to a standard format</description> <converter-id>CreditCardConverter</converter-id> <converter-class> converters Cred itCardConverter </converter-class>

</converter>

Conversores Propios

<render-kit> <renderer>

<component-family>Area</component-family> <renderer-type>DemoArea</rendere-type> <renderer-class>renderers.AreaRenderer</renderer-class> <attribute>

<attribute-name>onmouseout</attribute-name> <attribute-class>java.lang.String</attribute-class>

</attribute> <attribute>

<attribute-name>onmouseover</attribute-name> <attribute-class>java.lang String</attribute-class>

</attribute> <attribute>

<attribute-name>styleClass</attribute-name> <attribute-class>java.lang.String</attribute-class>

</attribute> </renderer>

Render Propio

Podemos registrar componentes visuales propios <component>

<component-type>DemoArea</component-type> <component-class>components.AreaComponent</component-class> <property>

<property-name>alt</property-name> <property-class>java.lang.String</property-class>

</property> <property>

<property-name>coords</property-.name> <property-class>java.lang.String</property-class>

</property> <property>

<property-name>shape</property-name> <property-class>java.lang.String</property-class>

</property> <component-extension> <component-family>Area</component-family> <renderer-type>DemoArea</renderer-type> </component-extension>

</component>

Componente Propio

Muestra una imagen. Propiedades de un, alt (texto alternativo,

normalmente mostrado al pasar el ratón por encima) y demás relativas al uso común en html (en la renderización típica Html).

<h:graphiclmage…./>

UIGraphic

Indica un dato de salida Con el Renderizador de Html tenemos

◦ outputLabel Su atributo ‘for’ apunta a un id de un campo de entrada

con el que se encuentra asociada la etiqueta

◦ outputLink Necesita una etiqueta verbatim que muestra el texto

que el usuario clickea para lanzar el link

UIOutput

◦ outputFormat que muestra un mensaje Permite la utilización de java.text.MessageFormat. Value indica la frase a parametrizar normalmente de un

ResourceBoundle. Tiene etiquetas de tipo <f:param value...> para indicar

los parámetros del mensaje.

◦ outputText que muestra un texto de una línea

UIOutput

06. JSF (Java Server Faces)

Documents

componentes jsf

defecto faces

servlet de jsf

jsfconfigurando jsf

librera estndar de jsf

defecto server

aplicaciones web

contenedor web