Fase 1: Restore View

Es esta primera fase se empieza a construir el árbol de componentes, llama al objeto UIViewRoot contenido en el FacesContext, del cual se obtendrá la información referente a la página. En esta fase el objeto UIViewRootse puede encontrar en tres estados diferentes:

New View: Construye un nuevo UIViewRoot y asocia los eventos y validadores a los componentes (Se hace una petición).

Initial View: Avanza directamente a la Fase 6. Esta vista se realiza cuando se carga la página por primera vez.

PostBack View: Cuando se vuelve atrás, se recupera la vista que esta guardada en el FacesContext.

Fase 2: Apply Request Values

En esta fase se asocian los valores que se encuentran en la petición a los componentes. Se comprueba el valor de la propiedad INMEDIATE que tienen los componentes. Esta propiedad sirve para capturar eventos y validaciones en esta fase del ciclo. El valor de la propiedad Inmediate es un Booleano:

False: Los valores simplemente se convierten, es decir, si para un campo se esperaba un entero se convierte el valor recogido a entero.Si se produce un error se guarda en el FacesContext y lo mostrará durante la Fase 6. 

True: Le componentos valores se convierten y se validan. Si hay eventos asociados a eses se capturan también. Igual que anteriormente si se produce un error se mostrará en la Fase 6. Cuando captures el evento para estos casos, podemos obligar a que directamente pase a la Fase 6 y validamos/convertimos solo pequeñas partes de la página si se producen eventos.
 

Fase 3: Process Validations

En esta fase se comprueban las reglas de validación que tienen asociadas los componentes. Si se produce algún fallo en la validación se corta el ciclo y se pasa directamente a la Fase 6. Los mensajes de error generados se guarda en el FacesContext.        

Fase 4: Update Model Values

En esta fase se actualizan el valor de las propiedades de los componentes en la clase Java. Se setean los valores de los componentes en el lado del servidor. Si no se validaron correctamente los componentes, obviamente los componentes del backing bean no se han actualizado.        

Fase 5: Invoke Application

Se capturan los envíos y peticiones que realiza el Form. Como los valores ya han sido convertidos, validados y aplicados a los componentes, se ejecuta la lógica de la página. Se controlarían en esta fase los eventos, la navegación entre páginas, etc.   
     

Fase 6: Render Response

Se muestra el UIViewRoot con todos los componentes en el estado que tengan asignado. Esto se recupera a través del FacesContext. Estas son las 6 fases por la que puede navegar la petición, si en cualquiera de ellas quisieramos pasar a la fase 6 directamente podríamos hacerlo mediante el metodo renderResponde() del FacesContext. Animo a crear un interceptor e ir probando con la propiedad inmediate y/o “cortocircuitar” fases para poder entenderlo mucho mejor. Como dije al principio del tema, esta explicado de la manera que yo lo he entendido, si alguien no está de acuerdo o quiere agregar más información, será bien recibida.

• adf-faces-10_1_3_0_4.zip
• JBoss Seam 1.1 1.1.1 GA

El Framework Jboss Seam lo podemos descargar directamente de la página oficial:
http://www.jboss.com/products/seam

En el paquete que nos descargaremos encontraremos las librerías necesarias, además de documentación y algunos ejemplos para que podamos ver el potencial del Framework. Entre las librerías que contiene, podemos encontrar las librerías de Hibernate y JSF, por tanto no será necesario que nos las bajemos nuevamente. Es conveniente estar al tanto de las actualizaciones que se hacen del Framework, pues corrigen muchos bugs y añaden nuevas funciones. Además si en algún momento exponemos alguna duda en los foros de Jboss, se nos exigirá estar utilizando la última versión disponible. Para descargar ADF debemos dirigirnos a la pagina Web de Oracle y descargarnos el paquete de librerías y ejemplos.

http://www.oracle.com/technology/products/jdev/ htdocs/partners/addins/exchange/jsf/index.html

En el paquete que actualmente hay para descargar (versión adf-faces-10_1_3_0_4.zip) hay un pequeño error. En la carpeta lib no aparece una librería que es necesaria para usar ADF. El nombre de esta librería es: adf-share.jar Abrimos Eclipse y procedemos a la creación de un nuevo proyecto. Añadimos a la carpeta lib las librerías necesarias.

Una vez que ya tenemos insertadas las librerías, lo único que nos quedaría por hacer es configurar el proyecto. Creamos un fichero vacio llamado seam.properties en el directorio raíz directorio src. En WEB-INF/ debemos crear 2 ficheros de configuración:

1. faces-config.xml: información referente al render-kit y el listener de Seam para los componentes.

<faces-config>
    <!-- Select one of the standard transaction models for the Seam application -->
    <lifecycle>
        <phase-listener>
        org.jboss.seam.jsf.SeamPhaseListener
        </phase-listener>
    </lifecycle>
    <application>
        <default-render-kit-id>oracle.adf.core</default-render-kit-id>
    </application>
</faces-config>

2. adf-faces-config.xml: información referente al skin que usaremos en los componentes ADF

<adf-faces-config xmlns="http://xmlns.oracle.com/adf/view/faces/config">
    <debug-output>true</debug-output>
        <!--client-validation-disabled>true</client-validation-disabled-->
        <accessibility-mode>
        #{prefs.proxy.accessibilityMode}
        </accessibility-mode>
        <!-- you can use EL to get the skin. This allows the skin to change between requests. -->
        <skin-family>#{prefs.proxy.skinFamily}</skin-family>
        <!--skin-family>oracle</skin-family--><!-- Uncomment any of these to enable them -->
        <!-- accessibility-mode>inaccessible</accessibility-mode -->
        <!-- A silly use of EL: English users get Simple Skin, others get Oracle Skin -->
       <!-- <skin-family>#{facesContext.viewRoot.locale.language=='en' ? 'simple' : 'oracle'}</skin-family -->
    <!-- oracle-help-servlet-url>
        http://helponline.oracle.com/jdeveloper/help/
        </oracle-help-servlet-url -->
</adf-faces-config>

Lo último que nos quedaría por hacer sería configurar en el fichero web.xml, los servlets de Seam, JSF y ADF para que mapeen nuestros ficheros JSP.

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.jsp</param-value>
    </context-param>
    <context-param>
        <param-name>facelets.REFRESH_PERIOD</param-name>
        <param-value>2</param-value>
    </context-param>
    <context-param>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.validateXml</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.verifyObjects</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>
            oracle.adf.view.faces.ALTERNATE_VIEW_HANDLER
        </param-name>
        <param-value>com.sun.facelets.FaceletViewHandler</param-value>
    </context-param>
    <!-- Seam -->
    <listener>
        <listener-class>
            org.jboss.seam.servlet.SeamListener
        </listener-class>
    </listener>
    <!-- MyFaces -->
    <listener>
        <listener-class>
            org.apache.myfaces.webapp.StartupServletContextListener
        </listener-class>
    </listener>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <!-- resource loader servlet -->
    <servlet>
        <servlet-name>resources</servlet-name>
        <servlet-class>
            oracle.adf.view.faces.webapp.ResourceServlet
        </servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsp</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>resources</servlet-name>
        <url-pattern>/adf/*</url-pattern>
    </servlet-mapping>
    <!-- Faces Servlet Mapping -->
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.seam</url-pattern>
    </servlet-mapping>
    <filter>
        <filter-name>adfFaces</filter-name>
        <filter-class>
            oracle.adf.view.faces.webapp.AdfFacesFilter
        </filter-class>
    </filter>
    <filter-mapping>
        <filter-name>adfFaces</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
</web-app>

Tras realizar todos estos pasos, ya estariamos preparados para comenzar nuestro nuevo proyecto web.

<navigation-rule>
    <navigation-case>
        <from-outcome>
            cadenaDeTexto
            <to-view-id>/ejemplo2.jspx
    </navigation-case>
</navigation-rule>

Si en algún componente le definimos un Action y en el metodo del bean le hacemos devolver una cadena. Este ira a buscar al faces-config si existe alguna regla de navegacion. Comparará la cadena que hemos devuelto con los from-outcome de los navigation-case.
 
Por tanto si en un metodo devolvemos como cadena : “cadenaDeTexto” nos redirigirá a la pagina ejemplo2.jspx. Si lo que quisieramos fuera redirigir a un popup cambiaria la manera de definir la regla de navegación y quedaría de la siguiente manera:

<navigation-rule>
    <from-view-id>
        /ejemplo1.jspx
        <navigation-case>
            <from-outcome>
                dialog:resumenPedido
                <to-view-id>/ejemplo2.jspx
        </navigation-case>
</navigation-rule>

La cadena de texto que debemos devolver ahora sería “dialog:resumenPedido” y de esta manera la página se abriría similar a un popup modal.

Para realizar este ejemplo simplemente tenemos que ir añadiendo los componentes en la página, colocarlos a nuestro gusto, y darle el comportamiento deseado. Dependiendo del IDE que utilizemos para ADF, el código de estos componentes se nos generará solo, o tendremos que escribirlo nosotros mismos. Una buena idea al empezar sería descargar el IDE gratuito de Oracle, JDeveloper, e ir investigando el código que generan los componentes.

Vamos a usar un componente llamado CorePanelForm para englobar en el a los dos cuadros de texto y al boton de envio del formulario. Vamos a crear también un objeto CoreMessages para sacar por la ventana un mensaje de error si el usuario no se loguea correctamente. Por tanto en la clase java tendremos que añadir los siguientes elementos:
 
private CoreMessages messages1;
private CorePanelForm panelForm1;
private CoreInputText inputText1;
private CoreInputText inputText2;
private CoreCommandButton commandButton1;

A estos objetos le añadiremos sus respectivos metodos get/set. Ahora lo que habría que hacer sería asociarle una acción al boton de envio del formulario, esto se puede hacer asociandole en la propiedad “Action” del boton el nombre del metodo mediante EL, y crearlo a mano en la clase java.

Un ejemplo de una accion que le prodríamos asociar al botón sería el siguiente:

public String enviarLogin(){
    
    if(getInputText1().getValue().equals("siglo") &&
    getInputText2().getValue().equals("siglo"))
    return "loginCorrecto";
    
    FacesContext.getCurrentInstance().addMessage(“Login Incorrecto”,
    new FacesMessage(FacesMessage.SEVERITY_WARN,
    "Login Incorrecto","Login Incorrecto"));
    
    return null;
}

Devolvemos un null pero podríamos haber devuelto cualquier otra cadena, mientras no este en la regla de navegación del faces-config irá dirigida la petición contra la página actual.

Lo único que quedaría por hacer sería añadir en el faces-config la regla de navegación:

<navigation-rule>
    <navigation-case>
        <from-outcome>
            loginCorrecto
            <to-view-id>/ejemplo2.jspx
    </navigation-case>
</navigation-rule>

Ya estaría completado este ejemplo.

Una posibilidad bastante útil es la de crear el componente en tiempo de ejecución, así ahorraríamos codigo extra en el fichero jspx y además nos da mucho más control de lo que queremos mostrar en la página. Con esto quitaríamos un peso innecesario a la carga inicial de la página, pues sólo cargaremos los componentes cuando los necesitemos.

La manera de crear un componente sería así:

    FacesContext.getCurrentInstance().getApplication().
       createComponent(COMPONENTE.COMPONENT_TYPE);

Esta llamada nos daría como resultado un Object que debemos castear al componente deseado:

   CoreInputText input = (CoreInputText)FacesContext.
        getCurrentInstance().getApplication().
        createComponent(CoreInputText.COMPONENT_TYPE);

Una vez que tenemos creado el componente, ya sólo nos quedaría darle los valores típicos de modo semejante a como lo hacemos en el jspx:

   input.setId("id1");
    input.setLabel("Etiqueta");

Del mismo modo que podemos crear componentes, podemos crear también validadores o converters en tiempo de ejecución, lo único que cambiaría es que en vez pasar como parametro la constante COMPONENT_TYPE pasaríamos otra constante llamada COMPONENT_FAMILY:

FacesContext.getCurrentInstance().getApplication().
       createComponent(Validator.COMPONENT_FAMILY);

Habrá veces que además de crear el componente, querramos asociarle acciones al mismo, y nos haga falta asociarle a un action un MethodBinding, la manera de crearlo no es muy complicada simplemente tenemos que saber cual es el nombre asociado al backing_bean y que valores va a recibir como parámetro el método al que lo vamos a asociar. La forma de realizarlo es usando el siguiente método:

FacesContext.getCurrentInstance().getApplication().
       createMethodBinding(String, Class[]);

Donde la cadena que recibe corresponde a la etiqueta EL que referencia al método que queremos llamar, es decir, “#{nombre_backing_bean.metodo}”, y como segundo parámetro recibe un array de las clases que va a recibir como parametros, como por ejemplo:

Class[] array = new Class[1];
    array[0] = ValueChangeEvent.class;

Este MethodBinding que recibiremos lo tenemos que asociar al componente, mediante su correspondiente setter.

Cuando creamos componentes, aunque no es requerido, siempre es conveniente setearle un id, hay un método que se puede acceder a él a través del FacesContext, que nos generá un id único para ese componente en la página, pero en páginas donde usemos a la misma vez varios objetos UIViewRoot este método puede causarnos muchos problemas, más que ayudarnos. Esto ocurre porque ese método simplemente recorre la lista de componentes existentes para ese objeto viewRoot y le asigna un valor correlativo al último encontrado. Por tanto, lo mejor siempre será asignarle el id de una manera segura y única para todos los casos que se puedan dar en la página. El método es el siguiente:

    FacesContext.getCurrentInstance().getViewRoot().
       createUniqueId();

Una vez que ya sabemos como crear componentes, validadores, etc sólo nos queda mostrarlos en algún lugar de la página, pues los tenemos creados, pero no posicionados. La manera de insertarlo en algún lugar de la página es muy sencilla, sería accediendo al metodo getChildren() de algún componente que permita insertarle hijos, y añadir nuestro componente. La forma de hacerlo es siempre la misma:

getPanel().getChildren().add(input);

Como ya comentamos en la página donde explicábamos las fases que se recorren durante el ciclo de vida, los diferentes valores que acepta la propiedad immediate serán true o false dependiendo de la fase donde queramos que se produzca la acción deseada. En el caso de las validaciones un valor u otro afecta a que tipo de validación se va a realizar, si de lado del servidor o de lado del cliente.

•    True: La validación en este caso se haría del lado del servidor, es decir, al setear la propiedad immediate a true hemos provocado que la validación se realize en la fase 2 y por tanto una vez que se envían los datos, antes de setear la propiedad al componente, se comprobará que se cumple la regla establecida. Si dicha validación es incorrecta, se generá un mensaje de error que es enviado al FacesContext. Dicho mensaje se mostraría por pantalla al usuario mediante el componente Messages.

•    False: La validación se haría del lado del cliente, pues el componente ya tiene la propiedad seteada y la comprobación se realizaría en la fase 3, cuando se realice la validación los componentes ya tienen seteados los nuevos valores, y el aspecto de la validación cambia, ahora se realiza dicha validación mediante javascript.

Hemos visto que la propiedad immediate modifica el comportamiento de los componentes según su valor, obliga a los componentes a validarse, convertirse y capturar sus eventos en unas fase u otra. Esto es algo a tener muy en cuenta pues si empezamos a setear el valor de esta propiedad de manera indiscriminada en la página podemos encontrarnos muchos quebraderos de cabeza que a simple vista no notaremos que son producidos por el valor de dicha propiedad. Normalmente, se usa el valor true para que los eventos, validaciones, etc los podamos capturar antes de que se les setee el valor a los componentes.

A continuación vamos a añadirle un validador a un campo de texto para ver el efecto de la propiedad immediate, si hacemos uso del primer ejemplo de login que hicimos podemos añadirle al campo de texto del login un componente de tipo RegExpValidator, dependiendo del IDE que utilizemos, podemos arrastrar el componente dentro del inputText o bien añadimos las siguientes etiquetas al JSP:

<af:inputText
    label="Escriba aqui"
    binding="#{condiciones.inputText1}"
    id="inputText1"
    autoSubmit="true"
    immediate="false">
    <af:validateRegExp pattern="[a-z]*”
     noMatchMessageDetail=”Validacion Erronea”/>
</af:inputText>

Los objetos de tipo RegExpValidator tienen 3 propiedades que son : pattern, noMatchMessageDetail e id. En este ejemplo el patrón que le hemos puesto sirve para que solo acepte caracteres en minúscula. Si ejecutasemos la aplicación y metemos unos campos erroneos, aparecera el mensaje de error.

Como hemos comprobado si tenemos puesta la propiedad immediate a false la validación se realiza con javascript, si cambiamos el valor de la propiedad a true veremos como esta se realizá ahora en el lado del servidor, enviando un mensaje de error al FacesContext. Tenemos que asegurarnos que tenemos en el JSP insertado un componente de tipo Messages:

<af:messages binding="#{condiciones.messages1}" id="messages1"/>

Espero que os haya servido este tutorial para aprender no ya de los validadores, sino de los efectos que pueden causar en la aplicación los valores de esta propiedad. Podeís probar a validar muchos campos a la vez y ver que es lo que más conviene para cada formulario.

El componente processTrain es un componente ADF del tipo menú. Consiste en crear varias páginas JSF que están enlazadas entre sí. Este componente actualmente está en discusión entre los creadores de ADF, pues su lógica se realiza en el fichero de configuración faces-config.

Las clases que se necesitan realizar para que funcione el componente básicamente son dos. Una nombrada por ellos como MenuItem y otra TrainModelAdapter. Estas dos clases están hechas ya por oracle, simplemente definen algunas propiedades que tendremos que usar luego desde el faces-config a la hora de definir los managed-bean y desde las páginas JSF para algunos valores del componente.

Clase MenuItem.java:
public class MenuItem {

/**
* Sets the property to use to get at view id
* @param propertyName
*/
public void setViewIdProperty(String propertyName) {
_propertyName = propertyName;
_model = null;
}
public Object getInstance() {
return _instance;
}
/**
* Sets the treeModel
* @param instance must be something that can be converted into a TreeModel
*/
public void setInstance(Object instance) {
_instance = instance;
_model = null;
}
public Object getMaxPathKey(){
return _maxPathKey;
}
public void setMaxPathKey(Object maxPathKey){
_maxPathKey = maxPathKey;
}
}

 
Una vez tengamos las páginas JSF que queramos meter en el menu, vamos al fichero faces-config y definimos los beans. Indicamos que el backing_bean es de tipo MenuItem y seteandole las propiedades por defecto. Un ejemplo sería el siguiente:

<managed-bean>
<managed-bean-name>paso1</managed-bean-name>
<managed-bean-class>view.backing.MenuItem</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>label</property-name>
<value>Paso1</value>
</managed-property>
<managed-property>
<property-name>viewId</property-name>
<value>/paso1.jspx</value>
</managed-property>
<managed-property>
<property-name>outcome</property-name>
<value>paso1</value>
</managed-property>
</managed-bean>

Ahora debemos irnos al faces-config y definir en él un backing-bean. Este realmente no lo tenemos creado como una clase se genera en tiempo de ejecucion. Definiremos que este backing-bean sea de tipo ArrayList y tendrá como valor los backing_bean que estan asociados con las páginas que queremos mostrar en el processTrain.

<managed-bean>
<managed-bean-name>createTrainNodes</managed-bean-name>
<managed-bean-class>java.util.ArrayList</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<list-entries>
<value-class>view.backing.MenuItem</value-class>
<value>#{paso1}</value>
<value>#{paso2}</value>
<value>#{paso3}</value>
</list-entries>
</managed-bean>

Y por último definimos la clase TrainModelAdapter en el mismo fichero de configuración faces-config:

<managed-bean>
<managed-bean-name>createTrainMenuModel</managed-bean-name>
<managed-bean-class>view.backing.TrainModelAdapter</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>viewIdProperty</property-name>
<value>viewId</value>
</managed-property>
<managed-property>
<property-name>instance</property-name>
<value>#{createTrainNodes}</value>
</managed-property>
</managed-bean>

 
Existen dos tipos de configuraciones para el componente processTrain, Plus One y Max Visited.
Si elejimos PlusOne el comportamiento será que el usuario puede avanzar los nodos de uno en uno de manera secuencial. Avanzaría del nodo 1 al 2, del 2 al 3, pero nunca del 1 al 5 por ejemplo. Pero si el usuario retrocede desde el nodo 5 al 1, cuando vuelva a avanzar tendría que pasar por todos los nodos anteriores.
Con MaxVisited el comportamiento sería semejante al anterior, pero se puede dirigir directamente a cualquier nodo que haya ya visitado.

Estos valores se definen en el managed-bean anterior, si ponemos la siguiente propiedad:

<managed-property>
<property-name>maxPathKey</property-name>
<value>TRAIN_DEMO_MAX_PATH_KEY</value>
</managed-property>

Aquí estaríamos usando la opción MaxVisited, si no pusieramos nada (null) usaría PlusOne.

Ya solo quedaría definir las reglas de navegación entre las páginas en el faces-config, la cadena que obtiene el componente para comprobar a donde se redirige se captura por la propiedad outcome definida para la clase MenuItem.

<navigation-rule>
<from-view-id>/paso2.jspx</from-view-id>
<navigation-case>
<from-outcome>paso1</from-outcome>
<to-view-id>/paso1.jspx</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>paso3</from-outcome>
<to-view-id>/paso3.jspx</to-view-id>
</navigation-case>
</navigation-rule>

Por último, en las páginas JSF, debemos de crear los componentes:

<af:processTrain var="train" value="#{createTrainMenuModel.model}">
<f:facet name="nodeStamp">
<af:commandMenuItem text="#{train.label}"
action="#{train.getOutcome}"
readOnly="#{createTrainMenuModel.model.readOnly}"
immediate="false"/>
</f:facet>
</af:processTrain>

El processTrain obtiene el modelo que se crea con la clase TrainModelAdapter y se lo setea como valor.

Él dinamicamente sabrá en cual página está y cual backing-bean usa en cada caso por la propiedad viewId.

Se puede añadir también a la página un componente processChoiceBar en el facet actions del panelPage. Este inserta en la parte superior e inferior de la página una guía de la navegación que tendría los mismos valores que el processTrain. Bastaría con añadir lo siguiente:

<f:facet name="actions">
<af:processChoiceBar var="choice"
value="#{createTrainMenuModel.model}">
<f:facet name="nodeStamp">
<af:commandMenuItem text="#{choice.label}"
action="#{choice.getOutcome}"
readOnly="#{createTrainMenuModel.model.readOnly}"
immediate="false"/>
</f:facet>
</af:processChoiceBar>
</f:facet>

Una vez completados estos pasos, si ejectusemos nuestra aplicación nos aparecería por pantalla el componente con las reglas de navegación que hayamos establecido anteriormente.

Una solución bastante efectiva es hacer uso de las librerías Captcha con la cual generabamos una imagen con un código que obligaba al usuario a introducirlo. En la nueva versión de JBoss Seam (1.1.6) esta librería viene integrada en el propio framework, permitiéndonos de una manera bastante sencilla integrarlo en nuestros proyectos.

En este tutorial vamos a explicar los pasos que tenemos que seguir para validar nuestros formularios con Captcha:

El funcionamiento de Captcha es un servlet, que nos genera la imagen con el código, y accediento al contexto de la página podemos sacar cuál es dicho código y validarlo. Por tanto, lo primero que debemos hacer, es definir el servlet en nuestro fichero de configuración web.xml:

<servlet>
<servlet-name>Captcha Servlet</servlet-name>
<servlet-class>
org.jboss.seam.servlet.CaptchaServlet
</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>Captcha Servlet</servlet-name>
<url-pattern>/captcha</url-pattern>
</servlet-mapping>

La manera de mostrar la imagen y validarla la realizaremos a través del framework JBoss Seam, para ello, como es habitual, usaremos también el framework ADF en la capa de vista, que es donde se mostrará la imagen con el código y por donde a través de dicho framework accederemos al contexto donde Seam tiene referenciado al servlet.

En la página JSF-ADF donde tengamos el formulario debemos de definir un componente objectImage donde mostraremos la imagen generada por Captcha:

<af:objectImage source="/captcha?#{captcha.id}" />

Sólo quedaría definir un componente inputText donde el usuario pueda teclear el valor aparecido en la imagen, y así, validarlo:

<af:panelLabelAndMessage
label="Codigo de la imagen">
<af:inputText value="#{captcha.response}"
requiredMessageDetail=
"El valor debe coincidir con la imagen"
required="true" immediate="true">
<s:validate />
</af:inputText>
</af:panelLabelAndMessage>

Seam, internamente, y haciendo uso de las librerías de Captcha, capturará el valor de la caja de texto y lo validará con el código de la imagen, cuando nuestro usuario pulse el botón para confirmar el usuario. Esto se produce gracias al valor true de la propiedad required. El valor introducido se guarda en el metodo del objeto Captcha alojado en el contexto de Aplicación que genera Seam. Si no ha sido validada la imagen, dicho metodo no se ejecutará.

Para insertar mensajes de error simplemente debemos llamar al objeto estático FacesContext y acceder al contexto actual de la página:

FacesContext facesContext = FacesContext.getCurrentInstance();

Una vez hemos recogido el objeto, debemos de llamar a uno de sus métodos que es addMessage(…), de manera intuitiva, gracias al javaDoc vamos a insertarle los valores a los parámetros que nos hacen falta:

facesContext.addMessage("cadena", new FacesMessage(FacesMessage.SEVERITY_ERROR, "cadena", "cadena"));

Si nos fijamos, el objeto FacesMessage es el que nos generá el tipo de mensaje que vamos a mostrar, que puede ser o de error, información, advertencia, etc.

Ahora vamos a recordar, que componente de ADF nos muestra la información generada por el FacesContext:

<af:messages>

Añadiendo este componente, cuando las peticiones lleguen a la Fase 6 del ciclo de vida, se seteará automaticamente el valor del componente con los mensajes que haya contenido en el FacesContext.

Además de para insertar mensajes, el objeto FacesContext tiene otras funcionalidades, que ya iremos viendo en futuros tutoriales.

Para crear un popup en ADF simplemente debemos definir una regla de navegación específica, la cual abrirá la nueva ventana en forma de popup, para ello, en el fichero faces-config.xml debemos escribir lo siguiente:

<navigation-rule>
<from-view-id>/ejemplo1.jspx</from-view-id>
<navigation-case>
<from-outcome>dialog:abrirPopup</from-outcome>
<to-view-id>/ejemplo2.jsxp</to-view-id>
</navigation-case>
</navigation-rule>

Al igual que cualquier otra regla de navegación, al ejecutar un metodo y devolver una cadena formateada como “dialog:abrirPopup” nos redirigirá a dicha página, pero esta vez en forma de popup.

Se puede dar el caso que queramos pasar valores a la nueva página que estamos abriendo, pues de igual modo que ocurriría si no fuera un popup, deberíamos llamar a la clase estatica AdfFacesContext y hacer lo siguiente en nuestro método asociado al action:

    AdfFacesContext().getCurrentInstance().getProcessScope().put ( " key " , " objeto " );

Si desde el backing_bean asociado al popup quisieramos recoger dichos valores se haría de la misma manera, pero en vez de setear los valores los recogeríamos:

    AdfFacesContext().getCurrentInstance().getProcessScope().get( " key " );

Lo único que nos quedaría por hacer sería asociarle una propiedad al botón que vaya a abrir el popup:
   
    useWindow = true;

De esta manera habríamos creado un sencillo popup en nuestra página. Existen otros medios para poder pasarle valores al popup, y sería asociandole un evento de tipo launchEvent al botón, y lo único que habría que hacer es capturar el componente y pasarle los valores de manera similiar a como hemos explicado anteriormente. El problema a esto es que a veces, queremos que según que tipo de condición se realice en el método asociado al evento se realice una navegación u otra, o que no se abra ningún popup.

Puede ocurrir que tengamos en el evento una condición que según el tamaño de una lista, se le envíen al popup ciertos valores, nuestra intención sería que si esa lista está vacia no se lance el popup sino que se envíe un mensaje al FacesContext. Los parametros se asociarían accediendo al launchEvent, recogiendo el componente y ejecutando el método getDialogParameters().put(....);

A la misma vez, se esta asociando un action al botón que lanza el popup, que se ejecutaría antes que el evento anterior, por tanto, se está estableciendo ya la cadena que se debe de retornar para lanzar el popup (dialog:…).

Si se nos diera el caso que no debemos lanzar el popup, mandamos el mensaje de error al FacesContext, aparecería pintado en la pantalla, pero como se ha definido la regla de navegación antes que se ejecute el evento, se nos abre también el popup.

La solución al problema sería eliminar ese launchEvent y ejecutar la lógica en el action, y los valores del popup pasarlos a traves del AdfFacesContext como se explico al principio del tutorial.