Fetishcode…Thinking in objects

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”);

Al crear un proyecto [JSF,ADF BC] Jdeveloper ya nos crea el fichero faces-config.xml. En este fichero se definen las reglas de navegación, los backing bean´s de cada una de las páginas, etc.

Pero llegado un momento, si nuestra aplicación es muy grande, podemos llegar a tener un faces-config.xml excesivamente grande y costoso de mantener.
Una buena política es intentar dividir nuestro faces-config.xml, de la misma manera que modulamos a la hora de programar, no estaría demás modular o separar, en la medida de lo posible, la configuración de nuestro proyecto.

Desde luego que para una aplicación pequeña y con un fichero faces-config.xml de 300 líneas no hace falta romperse la cabeza, pero cuando una ya lleva 3000 líneas, creo que es para planteároslo.

Para añadir un segundo fichero config deberemos añadir las siguientes líneas al fichero web.xml.

<context-param>
<param-name>javax.faces.CONFIG_FILES </param-name>
<param-value>/WEB-INF/faces-config.xml, /WEB-INF/tiles-defs.xml</param-value>
</context-param>

De esta forma la aplicación sabe que ademas del faces-config tiene otros dos ficheros de configuración.

A la hora de crear un jspx y su correspondiente backing bean es muy importante saber que ciclo de vida van a seguir.

De tal modo que por ejemplo un backing bean con scope request se crea por cada peticion, esto es muy importante a la hora de programar.
LifeCycle Support

“A requirement for IoC is handling lifecycle support. In fact JSF’s managed bean facility handles lifecycle support extremely well in that it is specifically geared toward defining lifecycle scope for HTTP requests as opposed to a more generic form which is common in other IoC containers. Similar to the scope parameters as specified by the JSP UseBean tag, the JSF scope sets the lifecycle with the following:
none: A managed bean with this scope is not stored anywhere, it is created “on demand” whenever it is needed.
request: A bean with a request scope will have it’s value stored only for the duration of a single request. Upon subsequent requests on the same object, a new clean version will be instantiated.
session: A bean with session scope will be stored onto the session meaning that the bean’s properties will stay alive during multiple requests. A shopping cart bean would be set to a session scope. Objects stored onto the session are naturally threadsafe and will expire when the session times out if not cleared by the application explicitly. You wouldn’t want anyone else looking in your shopping cart!
application: Objects created with application scope will exist during the entire lifetime of the container. An example of when usage makes sense could be for a JDBC datasource object. “

Mas información en este articulo de oracle:The JavaServer Faces Managed Bean Facility