Lanzamiento de Mensajes en ADF

Por Alejandro Font
Publicado en noviembre 2011

En este artículo tratare de explicar como podemos lanzar mensajes en nuestras aplicaciones ADF. Más concretamente nos centraremos en los mensajes JSF (FacesMessages) que podemos lanzar via Java.

El artículo se centra exclusivamente en lanzamiento de mensajes desde clases java. Aunque se hace uso de ficheros properties el articulo no tratara temas de internacionalización de aplicaciones.

Durante el artículo se hace alguna referencia a conceptos ADF pero no se entra en excesivo detalle ya que esta fuera del alcance del mismo.

Dentro de las aplicaciones ADF podríamos dividir los mensajes en dos grandes bloques.

• Mensajes a nivel de Pagina: Son mensajes que generalmente usamos cuando queremos ofrecer al usuario una información genérica de la pantalla en la cual se encuentra. Este tipo de mensajes se suele usar para informar del estado de un proceso, acción, etc.

Mensajes a nivel de Pagina

• Mensajes a nivel de Componente: Este tipo de mensajes se utilizan cuando queremos ofrecer al usuario una información que está vinculada a un componente de la pantalla, como podría ser un campo de texto, un campo de fecha. Es el tipo de mensaje que implementan típicamente los validadores. Este tipo de mensajes son muy útiles de cara al usuario ya que no solo le notifican un mensaje, sino que además le aportan información sobre que parte de la pagina le está dando dicho mensaje.

Mensajes a nivel de Componente

De manera adicional a esta primera clasificación, los mensajes pueden ser de diferentes tipos, según lo que se quiere indicar al usuario o la criticidad del propio mensaje.

Actualmente tenemos cinco tipos de mensajes:

• Fatal
• Error
• Warning
• Confirmation
• Info

Es importante que escojamos bien el tipo en base a la sensación e información que le queremos aportar al usuario ya que el framework nos aplicará un estilo para cada tipo. Y a nivel visual es muy importante que la información que recibe el usuario sea acorde con su estilo. No sería apropiado notificar que un proceso ha finalizado correctamente con un icono de Advertencia, por exponer un caso.

En la siguiente imagen podemos ver los diferentes mensajes que tenemos en ADF, y el estilo que se le aplica en tiempo de ejecución según su SEVERITY

diferentes mensajes que tenemos en ADF

El estilo, que aporta ADF a los mensajes, se puede modificar vía Skin, pero eso esta fuera del alcance que hoy nos ocupa, quizá lo tratemos en otro artículo.

Una vez hecha las distintas clasificaciones vayamos al código. A continuación veremos cómo lanzar cada uno de los distintos mensajes desde nuestras clases beans, que gestionan nuestras paginas jspx.

1. Lanzando un mensaje a nivel de pagina en ADF.

FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_INFO, null, "Mensaje de info");
FacesContext.getCurrentInstance().addMessage(null, msg);

Lo primero es crear el mensaje. Al crearlo le indicamos el texto de dicho mensaje y le debemos aplicar un tipo. El tipo lo cambiamos mediante el primer parámetro FacesMessage.SEVERITY_FATAL, FacesMessage.SEVERITY_ERROR, FacesMessage.SEVERITY_WARN, FacesMessage.SEVERITY_INFO

Una vez creado el mensaje lo añadimos al FacesContext.

Como se ha comentado anteriormente estos mensajes son en realidad mensajes JSF estándar por lo que para obtener más información sobre estos podéis dirigiros a la Api de FacesMessage:

http://download.oracle.com/docs/cd/E17802_01/j2ee/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/application/FacesMessage.html

Para el cuarto tipo, el de Confirmacion, la cosa cambia un poco ya que es un mensaje que no se construye mediante la api de JSF sino con una clase propia de ADF:
oracle.adf.view.rich.util.FacesMessageUtils

FacesContext.getCurrentInstance().addMessage(null, FacesMessageUtils.getConfirmationMessage(null,"Mensaje de Confirmacion"));

Los mensajes a nivel de pagina suelen salir en forma de popup y centrados, tal como podemos ver en la siguiente imagen.

mensajes a nivel de pagina suelen salir en forma de popup y centrados

Una de las posibilidades que tenemos cuando creamos un mensaje es no enviar un String con texto simple sino que podemos formar una cadena cona tags html por lo que podemos fácilmente darle un formato más rico a nuestros mensajes.

2. Lanzando un mensaje a nivel de Componente en ADF.

Lanzar un mensaje a nivel de componente es lo mismo que hacerlo de forma genérica, pero esta vez al añadirlo en el FacesContext le indicamos el id del componente al cual queremos asociar el mensaje.

getItlocation().getClientId.

En este caso el InputText del campo Location esta "bindeado" en el Bean, mediante la propiedad binding

FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_INFO, null, "Mensaje de Informacion relativa al Componente");
FacesContext.getCurrentInstance().addMessage(getItlocation().getClientId(FacesContext.getCurrentInstance()), msg);

En la imagen siguiente podemos observar como el mensaje de información está relacionado con el campo LocationId

campo LocationId

Hasta el momento, en los ejemplos que hemos visto, el texto de los mensajes estaban puestos de forma directa en el código, pero en una aplicación real seguramente tendremos un fichero properties o similar de donde sacar el texto de nuestros mensajes.

Para ello previamente tendremos que haber registrado nuestros properties en nuestra aplicación de cara a que soporte ficheros de properties y multiidioma.

Para ello deberemos registrar nuestro fichero properties y los idiomas soportados por la aplicación en el faces-config.xml

Es importante destacar que los métodos expuestos tienen en cuenta el locale actual, por lo que en caso de tener varios ficheros properties para el tema de la internacionalización de nuestra aplicación, dichos métodos obtendrían el mensaje del properties correspondiente al locale del usuario.

faces-config.xml

3. Obtener el texto de un properties.

Una vez configurado nuestro Bundle e idiomas podemos lanzar mensajes, desde java, cuyos textos vengan de nuestro properties.

Bundle

Para ello necesitaremos algún método auxiliar como getBundle

private static ResourceBundle getBundle(String nameBundle) {
FacesContext fc = getFacesContext();
return fc.getApplication().getResourceBundle(fc,nameBundle);
}

FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_INFO, null, 
getBundle("res").getString("mensajeNormal"));

FacesContext.getCurrentInstance().addMessage(null, msg);

El bundle lo obtenemos a través de su Var Name mapeado en faces-config.xml una vez obtenido podemos obtener cualquier entrada mediante su clave.

4. Sustituir parámetros de un properties.

Otro caso típico es que tengamos mensajes dinámicos, es decir mensajes con parámetros que se sustituirán en tiempo de ejecución al lanzar el mensaje.

En la siguiente imagen podemos ver el mensaje del properties con clave mensajeParametros ya con los parámetros sustituidos

mensaje del properties con clave mensajeParametros

Object[] params = new Object[2];
 params[0]  = "a" ;
 params[1] = "b";
      
FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_INFO, null,    
MessageFormat.format(getBundle("res").getString("mensajeParametros"),params));
 
FacesContext.getCurrentInstance().addMessage(null, msg);

Este tipo de mensajes parametrizados suele ser muy típico en validaciones y procesos. Por eso como uno de los últimos puntos de este articulo veremos cómo poder lanzar mensajes de este tipo desde validaciones Groovy con ADF BC

5. Mensajes parametrizados en validaciones de Groovy

A continuación veremos cómo aplicar esta sustitución de parámetros en validaciones tipo Groovy.

Como podemos observar en la imagen siguiente tenemos una regla de validación de tipo Groovy, cuyo mensaje tiene varios tokens o parámetros que serán sustituidos en tiempo de ejecución.

El mensaje es el siguiente:

El campo {1} con tooltip{2} no puede ser mayor que {3}. Y usted ha introducido {4} y antes teniamos {5}

En el ejemplo, estos cinco token se sustituyen en tiempo de ejecución por las siguientes expresiones:

1. adf.object.hints.nombreAtributo.label
2. source.hints.nombreAtributo.tooltip
3. 15
4. newValue
5. oldValue

Además de los token o parámetros también podemos indicar el tipo del mensaje

parámetros también podemos indicar el tipo del mensaje

Al saltar la validación del campo el mensaje de dicha validación es convertido a un mensaje de tipo componente asociado al campo. Finalmente este es el resultado:

validación del campo

6. Obtener mensaje de un fichero properties desde la capa de Modelo.

Hasta ahora todos los ejemplos que hemos implementado, exceptuando el de Groovy, estaban en la capa ViewController. Pero generalmente tenemos un fichero properties por proyecto o capa asi que para finalizar veremos cómo obtener mensajes vía Java desde la capa de Modelo.

//implementado en la clase ViewImpl

public String getMensaje(){
 ResourceBundleDef resourceDef = this.getResourceBundleDef();
 Locale locale = this.getApplicationModule().getSession().getLocale();
 return StringManager.getLocalizedStringFromResourceDef(resourceDef, "mensajeModelo",null, locale, null,false);
}

Nota: Esto solo es un ejemplo ilustrativo que podría ser útil en algún caso especifico, pero no debería utilizarse en una validación de ADF BC ya que el propio framework se encarga de obtener el mensaje del bundle para cada una de las validaciones que se pueden implementar a nivel de Entidad.

Con este artículo hemos podido ver como lanzar mensajes vía Java desde nuestras aplicaciones ADF, pero se ha de tener en cuenta que esto solo es una de las muchas maneras que tenemos en el framework, de comunicarnos con el usuario de la aplicación. Y en muchas ocasiones haremos uso no solo de este tipo de mensajes, sino de dialogs o popups que no solo dan información al usuario sino que además le permiten tomar decisiones en base a preguntas que la propia aplicación le lanza.

En este punto ADF como framework aporta un valor muy importante teniendo muy unida su capa de Modelo y reglas de Negocio con la gestión de mensajes de dichas reglas y procesos aportando una alta usabilidad al usuario y una alta productividad a los equipos de desarrollo.




Publicado por Alejandro Font. Bloggers regionales externos pero que conocemos.