Fetishcode…Thinking in objects

Que nos ofrece un framework de desarrollo como JSF. Estos son algunos de los puntos calves que nos ofrece afrontar nuestros desarrollos con JSF como base.

• Modelo de componentes reutilizables
• Control de datos asociados a cada componente de interfaz
• Focalizar los esfuerzos en la aplicación
• Gestion de mensajes
• Gestion de Errores
• Definición de un método para crear nuevos componentes
• Separación de la capa de presentación
• Diferenciación de roles
• Estandarización
• Gestión de las navegaciones
• Validaciones

Independientemente de JSF, un framework siempre nos debería aportar

• Productividad
• Best practices y patrones de diseño
• Calidad, estructuracion
• Mantenibilidad
• Flexibilidad
• Apertura en el mercado

Mas info: Framework

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.

No podiamos empezar Septiembre de mejor manera. En Jdevloperla se publica el primer artículo sobre sobre ADF Y Jdeveloper 11g.

Les dejo el enlace al articulo: Desarrollando una Rica Interfaz de Usuario con AJAX y JSF .

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.

Cuando trabajamos con ADF Faces y queremos abrir un enlace en una nueva ventana, es decir hacer uso de target=”_blank” tenemos varias opciones.

Una es hacer uso del componente golink y la propiedad targetFrame

<af :goLink destination="http://www.fetishcode.wordpress.com" targetFrame="_blank"/>

Otra opción, es hacer uso de la propiedad target del propio form. Esta última es útil cuando tenemos la necesidad de hacer uso de commandbuttons o commandlinks.

<h :form target="_blank"> </h>

Método que dado el nombre de un ViewObject y una lista de keys nos realiza una búsqueda mediante el método findByKey y nos setea la primera de las rows como currrentRow.

    public void setCurrentRowViewObject(String nomview, List l){
     try{
            Iterator it = l.listIterator(0);
            ViewObject vo=findViewObject(nomview);
            Object[] keyValues=new Object[l.size()];
            for(int i=0; it.hasNext();i++){
                       Object item = it.next();
                       keyValues[i]=item;
            }

            Row[] r = vo.findByKey(new Key(keyValues),1);
            if (r != null && r.length > 0) {
                vo.setCurrentRow(r[0]);}
        } catch (Exception ex)  {}
    }

Un método muy útil para tener en nuestra clase de Utils o en nuestro AppmoduleImpl.

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.

Uno de los problemas mas comunes al desarrollar con ADF, una vez hemos pasado de la fase inicial de típicos Maestro/Detalle, es el famoso selectonechoice o lista despegable dentro de una tabla.

Para conseguirlo debemos recorrernos los elementos de la lista mediante un for each.

Les dejo un ejemplo en formato vídeo de Steve Muench.

Espero que en la nueva y esperada version 11g, este tema este mejor planteado.

How to use and configure ADF Logger

El sistema de trazas o logging que utiliza ADF se denomina Java Logging . Este sistema de trazas no requeire el uso de ninguna librería extra ya que viene incluida en el propio JDK, desde la version 1.4.

Para poder hacer uso de este sitema de trazas en nuestro proyecto bastara con registrar un logger en la clase:

private static Logger logger = Logger.getLogger("milog");
logger.info("info");
logger.fine("fine");

El fichero dec onfiguración del sistema de trazas se llama logging.properties y se encuentra en: /jdk/jre/lib/logging.propertiesTambién podemos indicar un fichero propio, en tiempo de diseño, idicándolo en JDEV_HOME/jdev/bin/jdev.conf mediante la siguiente linea:
AddVMOption -Djava.util.logging.config.file=path y nombre del fichero propertiesPor otro lado todos los loggers que ADF utiliza los tiene registrados y configurados en el fichero j2ee-logging.xml que lo encontramos…
Dentro del Jdeveloper en: /jdev/system/oracle.j2ee.10.1.3.xx.xx/embedded-oc4j/config
en el OAS: /j2ee//config
Y en un OC4J en: /j2ee/home/configOtra opción, y quizá la mas extendida, es configurar nuestro proyecto para Jakarta-Log4j.

Mas información: ADF-Logging

Muchas veces cuando desarrollamos una aplicación, hay ciertas partes que siempre se repiten como es el logo, la sección de información de usuario, etc.

En general estas partes estas determinadas por lo que en ADF/JSF se denominan PanelPage Facets, tal como podemos ver en la guía ADF Developer’s Guide.

Lo ideal a la hora de desarrollar nuestras pantalla seria que ciertas secciones comunes las definiéramos en un solo lugar. De esta forma solo deberemos hacer cambios en ese lugar y se reflejara en todas las páginas de la aplicación. Tendriamos una especie de plantillas.

Par conseguir esto podemos hacer uso de jsp:incluye:

<f:facet name="menuGlobal">
<f:subview id="globalMenufragment">
<jsp:include page="/plantillas/plantillaglobalMenu.jspx"/>
</f:subview>
</f:facet>

O de las regions:

  <af:region regionType="oracle.adfdemo.region.stock" >
   <f:attribute name="symbol" value="ORCL"/>
   <f:attribute name="desc" value="Oracle Corp"/>
 </af:region>