Fetishcode…Thinking in objects

CreditCard Validator in JSF

Implementamos el validador:

package view.validators;
import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.validator.Validator;

import javax.faces.validator.ValidatorException;

public class ValidatorCreditCard implements Validator{
    //Credit card validator for AMEX, VISA, MasterCard only.
    //Allows spaces, dashes, or no separator between digit groups according to the layout
   // (4-6-5 for AMEX, 4-4-4-4 for Visa and Mastercard)
    String regex="^((4\\d{3})|(5[1-5]\\d{2}))(-?|\40?)(\\d{4}(-?|\40?)){3}|^(3[4,7]\\d{2})(-?|\40?)\\d{6}(-?|\40?)\\d{5}";

    public void validate(FacesContext facesContext, UIComponent uiComponent,
                         Object object) {
        String val = (String)object;
        if (!val.matches(regex)) {
            throw new ValidatorException(new FacesMessage("La Tarjeta de Credito no es valida"));
           }
    }
}

Lo registramos en el faces-config:

 <validator>
<validator-id>ValidatorCreditCard</validator-id>
<validator-class>view.validators.ValidatorCreditCard</validator-class>
</validator>

Lo usamos en nuestro componente:

 <af :inputText value="#{bindings.numeroTarjetaCredito.inputValue}"
                                label="#{bindings.numeroTarjetaCredito.label}"
                                required="#{bindings.numeroTarjetaCredito.mandatory}"
                                columns="#{bindings.numeroTarjetaCredito.displayWidth}"
                                binding="#{backing_paginas_pagoTarjeta.inputText1}"
                                id="inputText1" autoSubmit="true">
                                <af :validator binding="#{ValidatorCreditCard}" validatorId="ValidatorCreditCard"/>
                  </af>

PrettyFaces es una extensión que podemos aplicar a nuestras aplicaciones JSF y que nos proporciona un mecanismo para obtener unas url´s mas bonitas y amigables en la aplicación.

Substituyendo el típico /faces/page.jsf por /mapped/page.

Además esta pequeña extensión nos proporciona otras características muy interesantes como poder llamar a métodos antes de la renderización de las páginas.

El código se distribuye bajo licencia GPL 3

Mas información :

• http://ocpsoft.com/prettyfaces/
• http://code.google.com/p/prettyfaces/

Implementar un filtro que verifique para cada una de nuestras peticiones si el usuario esta loginado “Login check”, se suele hacer generalmente con un filtro del tipo ServletFilter.

Es por eso que aquí les dejo otra forma, quizá no tan conocida. Utilizar PhaseListener, es decir el propio Listener de las fases del ciclo de vida de nuestra aplicación JSF nos validara las peticiones.

Aquí pueden ver la clase:

package view;

import javax.faces.application.NavigationHandler;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseListener;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;

public class MyPhaseListener implements PhaseListener {
    public MyPhaseListener() {
    }

    public void beforePhase(PhaseEvent pe) {
        if (pe.getPhaseId() == PhaseId.RESTORE_VIEW){
            System.out.println("Procesando nueva Peticion!");}
        System.out.println("before - " + pe.getPhaseId().toString());
    }

    public void afterPhase(PhaseEvent pe) {
        FacesContext fc = pe.getFacesContext();
        System.out.println("after - " + pe.getPhaseId().toString() + "---" + pe.getFacesContext().getViewRoot().getViewId());

        if (pe.getPhaseId() == PhaseId.RESTORE_VIEW){
            System.out.println("Miramos si esta logeado!");

            boolean loginPage =fc.getViewRoot().getViewId().lastIndexOf("login") > -1 ? true : false;
            if (!loginPage && !loggedIn()) {
                      NavigationHandler nh = fc.getApplication().getNavigationHandler();
                      nh.handleNavigation(fc, null, "logout");
            }   
        }

        if (pe.getPhaseId() == PhaseId.RENDER_RESPONSE){
            System.out.println("Peticion Procesada!");}

    }

    private boolean loggedIn() {
        //TODO
        //implementar un metodo de validacion de login
    }

    public PhaseId getPhaseId() {
        return PhaseId.ANY_PHASE;
    }
}

Llegados a este punto quizá se abre un debate interesante:

Que forma es mejor, si es que hay una mejor. La configuración es distinta para cada una de las opciones ya que ServletFilter se configura en el web.xml y podríamos decir que sirve para cualquier aplicación web en cambio mediante la opción PhaseListener nos adentramos mas en JSF y se configura en el faces-config.xml.

En Jdevloperla publicamos un nuevo articulo, dentro de la secciona JSF, Conversores en JSF, donde se trata el tema de las conversiones estandars en JSF y como crear nuestros propios conversores.

En algunos posts anteriores comentábamos que no siempre sacamos el máximo del .jspx en nuestras aplicaciones JSF. A menudo olvidamos que una de las partes fundamentales que componen JSF es un lenguaje de expresiones ( EL) .

A continuación les dejamos un enlace de Sun donde explican en detalle todas las operaciones que podemos realizar mediante EL, JSF Expression Language.

Muchas veces cuando desarrollamos en ADF/JSF nos limitamos a hacer uso de los componentes que ofrece la librería de componentes adf faces, xmlns:af=http://xmlns.oracle.com/adf/faces , y dejamos de lado otras librerias.
Es el caso de una librería tan potente como JSTL(JavaServer Pages Standard Tag Library)xmlns:c=http://java.sun.com/jsp/jstl/core.Esta librería nos permite poder realizar ciertas rutinas de programación como son la declaración de variables, condicionantes, recorridos,etc.

Para poder hacer uso de ella simplemente hay que añadir al principio del jspx

<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:af="http://xmlns.oracle.com/adf/faces"
          xmlns:afh="http://xmlns.oracle.com/adf/faces/html"
          xmlns:c="http://java.sun.com/jsp/jstl/core">

Y hacemos uso de de ella con el prefijo c.

Seguramente el poco uso que yo he visto de esta librería se deba a que cuando se quiere realizar algun tipo de programación asociada a la página se hace uso de los backings, managed beans o de la capa de Modelo.

Quiza muchos de ustedes ya conocen esta librería o han trabajado con struts o jsp pero aquí les dejo el enlace para todos aquellos que quieran darle un añadido a sus páginas.

API-JSTL
JavaServer Pages Standard Tag Library

this post explain how display and getting the date in a selectInputDate and on the other hand explain one of the possibilities of getting current date in java

Cuando trabajamos con selectInputDate es frecuente tener que cargar la fecha actual, recoger la fecha en cierto formato, etc.

Para cargar la fecha actual en el campo nada mas se cargue la página haremos uso del método set del componente en el backing bean.

public void setSelectInputDate1(CoreSelectInputDate selectInputDate1) {
       this.selectInputDate1 = selectInputDate1;
       this.selectInputDate1.setValue(getfecha());
}

y para obtener la fecha actual hay diversas maneras…cada una con sus mas y sus menos.

A mí me gusta esta:

private String getfecha(){
     SimpleDateFormat formatter = new SimpleDateFormat ("dd/MM/yyyy");
     java.util.Date factual = new java.util.Date();
     String dateString = formatter.format(factual);
     System.out.println("--> Date actual: " + dateString);
     return dateString;
}

Hay que tener cuidado con los patrones de SimpleDateFormat ya que MM no es lo mismo que mm.
Por último para recoger el valor de un selectInputDate podemos cargar un valueChangeListener e implementarlo de la siguiente forma.

public void seleccionFechaChange(ValueChangeEvent valueChangeEvent) {
   SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
   String fecha=(format.format(getSelectInputDate1().getValue()));
   System.out.println("fecha: " +fecha);
}

Hace unos días hemos subido un articulo sobre las distintas validaciones en JSF en el portal de Jdeveloperla.

Aqui tienen el enlace, validaciones en JSF

Espero que les sea de utilidad.

this post explain how to ensure that the code will be executed only one time using Postback condition

Hay veces que queremos realizar una tarea solo al principio, al cargar la pagina.
Lo mas lógico seria intentar implementar dicha tarea o método en el backing, mas concretamente en el setbindings o en el constructor del bb. Entonces nos encontramos que si nuestro scope es de tipo request pasaremos por dichos métodos cada vez que se realice una petición en la pagina.

Para solucionar esto podemos jugar con la siguiente condición:

.if(!AdfFacesContext.getCurrentInstance().isPostback()){
//the code
}

De este modo garantizamos que solo se ejecutara una sola vez, al cargarse la pagina. Independientemente del tipo de scope de nuestro backing bean.

A veces cuando desarrollamos aplicaciones necesitamos disponer de ciertos parámetros o variables globales.

Una forma sencilla de crear esos parámetros y poder consultarlos en cualquier momento desde nuestro proyecto es definirlos en el fichero web.xml.

<context-param>
<description>Servidor de correo de sistema</description>
<param-name>NUESTRO_PARAMETRO</param-name>
<param-value>parametro</param-value>
</context-param>

Una vez mapeado nuestro parámetro se puede acceder a el desde el bb de la siguiente forma:

String param = FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(“NUESTRO_PARAMETRO”);