1. Nadie lee este miserable blog
2. Nadie lee el tutorial
3. JSF/Java/Etc me están decepcionando mucho
4. Hace rato que estoy por empezar a usar Django…
5. … ya falta poco para que empiece a usarlo
6. Ya salió la versión 1 de Django
7. Django es más lindo
8. Más rápido
9. Más liviano
10. Menos rompebolas
11. Está en Python
12. Me fui de tema…
13. En fin, porque no tiene sentido ya seguir con este tutorial

Espero que a alguien le haya servido lo poco que escribí, y que le sirva lo que escribiré más adelante cuando tenga tiempo, sobre otros temas de desarrollo.

El blog sigue la misma onda, pero intentaré incorporar más que nada noticias del mundo del desarrollo y demás yerbas…

Apenas tenga algo de tiempo y ganas, pretendo darle a este blog la vida que no tiene y que no tuvo el anterior.

Saludos!

The Doctor

Con el Expression Language (Leguaje de expresión o EL) podemos acceder directamente a las propiedades o métodos de los beans desde el código de las páginas (JSP, XHTML, etc), sin más trámite que el siguiente:

#{nombreDelBean.propiedad}

Fácil, ¿no? Ahora vamos a profundizar un poco porque sino no tiene sentido hacer una nueva entrega del tutorial =D.

Empecemos describiendo las ventajas del EL

• Notación breve
• Acceso a colecciones. Ej: #{variable[indiceOKeyWord]}
• Acceso a datos de “request”. Ej: #{propertiesVar['nombre']} (accediendo a un archivo de propiedades previamente cargado en la página)
• Uso de operadores (aritméticos, lógicos, etc)
• Salida condicional. Ej: #{test ? opcion1 : opcion2}
• Conversión de tipos automática
• Valores vacíos en caso de String nulo

Para poder utilizar JSF EL es necesario un server que soporte JSP 2.0 (como Tomcat 5)  o superior (servlet 2.4 al menos), lo cual nos lleva a tener un web.xml como el del código siguiente:


<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app 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 web-app_2_4.xsd"
version="2.4">
…
</web-app>


Accediendo a propiedades anidadas de un bean

En la entrega anterior vimos como se accedía a propiedades y métodos de los beans en el caso de que estos estén directamente declarados en el mismo bean (cabe aclarar que para poder acceder deben poseer sus respectivos getters y setters.) Ahora veremos como se accede a propiedades de objetos más complejos declarados en el bean (aunque no cambia mucho de la anterior.) Supongamos que en el managed bean tenemos un atributo del tipo Usuario, el cual posee a su vez dos atributos String, nombre y apellido; para obtener por ejemplo el nombre del atributo usuario de managedBean mediante EL, haríamos:

#{managedBean.usuario.nombre}

Esto hace que EL busque primero una variable o un managed bean, luego acceda a la propiedad “usuario” de éste, y por ultimo acceda  la propiedad nombre desde allí (todo mediante los getters, ej: getUsuario). Así de fácil, prácticamente igual que acceder a una propiedad simple.

En el caso de que en vez de mostrar esta propiedad mediante, por ejemplo, un <h:ouputText />, queramos modificarla con un <h:inputText />, la forma de utilizar EL será la misma, simplemente lo colocaremos en el atributo value del tag. La diferencia radica en que JSF buscará un setter aparte del getter, a la hora de acceder a la propiedad (el getter en el momento de renderizar y el setter al hacer submit.)

Accediendo a colecciones

Acceder a colecciones utilizando EL es muy sencillo y utiliza la misma notación para varios tipos de colecciones, veamos un ejemplo:

#{managedBean.coleccion[index]}

ó

#{managedBean.coleccion[key]}

Esto funciona con:

Array: unArray[index]

List: unaLista.get(index) ó unaLista.add(index, valor)

Map: unMapa.get(key) ó unMapa.put(key, valor)

En el caso de los HashMap, una forma equivalente puede ser:

#{unHashMap.key}

Como pueden ver, la forma en que EL accede a las colecciones es muy fácil e intuitiva, como ya veníamos viendo.

El Expression Language de JSF tiene también variables predefinidas (objetos implícitos) al igual que JSP (son casi los mismos), pueden leer un poco más sobre eso siguiendo este link, y sobre el mismo tema pero en JSP (para ver que objetos existen) siguiendo este otro. Ambas páginas en inglés.

Operadores de EL

En caso de que sea necesario hacer comparaciones para tomar alguna decisión de renderizado, pueden utilizarse operadores en EL:

Aritméticos: + – * / div % mod
Relacionales: == eq != ne < lt > gt <= le >= ge
Lógicos: && and || or ! Not
Empty: empty es True para null, empty string, empty array, empty list, empty map. False en otro caso.

Puede utilizarse evaluacíon condicional de la forma #{test  ? exp1 : exp2}, pero en estos casos generalmente es más recomendable recurrir a JSTL, que es más completo y funciona mejor.

Espero que les haya sido de utilidad esta entrega del Tutorial de JSF, que a pesar de las demoras entre artículo y artículo, seguiré publicando en la medida que pueda. No olviden dejar sus comentarios y dudas, me animan a seguir escribiendo!

Flujo de control de navegación simplificado

• Se muestra un form
• El form se hace submit a sí mismo
• Se instancia el bean
• Se llama al método de la acción
• El método de la acción retorna una condición
• Se muestra una pantalla de resultado

Para poder desarrollar esta parte del tutorial, vamos a necesitar:

• Mapeos en el archivo faces-config.xml
• Un form
• Un managed bean

Vayamos paso por paso, primero:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

...
<faces-config>
 <managed-bean>
  <managed-bean-name>loginBean</managed-bean-name>
  <managed-bean-class>com.ejemplo.login.LoginBean</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
 </managed-bean>
 <navigation-rule>
  <display-name>Login page</display-name>
  <from-view-id>/public/login/login.jsp</from-view-id>
  <navigation-case>
   <from-outcome>success</from-outcome>
   <to-view-id>/public/login/loggedin.jsp</to-view-id>
   <redirect/>
  </navigation-case>
  <navigation-case>
   <from-outcome>failure</from-outcome>
   <to-view-id>/public/login/loginerror.jsp</to-view-id>
   <redirect/>
  </navigation-case>
 </navigation-rule>
 ...
</faces-config>

Con este archivo de configuración hemos hecho dos cosas:
Declarar el managed bean como de sesión, para que mantenga su estado entre llamadas, y además Indicar reglas de navegación para que al recibir un String desde el login.jsp, jsf pueda determinar que camino tomar, en nuestro caso:

• “success”: redirecciona a loggedin.jsp
• “failure”: redirecciona a loginerror.jsp

Ya veremos luego como hacer que lleguen estos strings a JSF para que pueda decidir, es más facil de lo que pueden llegar a imaginarse, pero por ahora pasemos a…

El form es la parte del sistema mediante la cual el usuario se comunicará con el managed bean, y el código para crearlo sería más o menos como el que sigue:

1
2
3
4
5
6
7
8
9
10
11
12
13

<h:form id="loginForm">
    <h:outputLabel value="Usuario" />
    <h:inputText value="#{loginBean.userName}"
        id="usernameInput" size="20" tabindex="1">
    </h:inputText>
 
    <h:outputLabel value="Contraseña" />
    <h:inputSecret value="#{loginBean.password}"
	id="loginPasswordInput" size="20" tabindex="2">
    </h:inputSecret>
 
    <h:commandButton value="Entrar" action="#{loginBean.logged}" id="login" />
</h:form>

Vamos a destriparlo un poco para ver si se entiende mejor. Descartemos en principio las partes menos importantes, los atributos size y tabindex, y los tag no son realmente necesarios para el ejemplo, pero los coloqué igual para que quedara un poco mejor presentado el form. Considerando que los h:outputLabel sólo muestran las etiquetas de las cajas de texto, sólo nos quedan los inputs y el button, que son lo que importa.

Veamos los inputs, de a uno:

1
2
3

<h:inputText value="#{loginBean.userName}"
    id="usernameInput" size="20" tabindex="1">
</h:inputText>

Este tag es sencillo, genera un Input HTML del tipo “text”, y se conecta al atributo userName de nuestro managed bean (el cual aún no hemos codificado) mediante el value=”#{loginBean.userName}”, utilizando el nombre que declaramos para el bean en el faces-config.xml (loginBean, con minúscula al comienzo). Ahora ya empezamos a ver cosas “raras” como #{loginBean.userName}, y quizás tenga que explicar un poco más de que se trata. Si bien podría estar largo rato explayandome sobre este tema, me parece más correcto resumirlo sólo para saber para que lo utilizaremos. Cuando necesitemos acceder a atributos o métodos de los managed beans, usaremos algo llamado Expression Language (EL), implementado inicialmente por JSP en la forma ${bean.atributo} y luego modificado para JSF, con ciertas mejoras y un ligero cambio en su sintaxis: #{bean.atributo}; sí, sólo cambia el “$” por el “#”. Como podrán darse cuenta, este método de acceso a los atributos y métodos del managed bean puede simplificarnos mucho la vida .

Ahora vamos con el de la contraseña:

1
2
3

<h:inputSecret value="#{loginBean.password}"
    id="loginPasswordInput" size="20" tabindex="2">
</h:inputSecret>

¿Qué tiene de diferente este con el anterior? Bien, sólo que en vez de renderizarse como un Input tipo “text” HTML, lo hace como uno del tipo “password” así se enmascara el texto escrito en él. Simple, ¿No?

Ahora pasamos al button, que también es muy facil de entender.

1

<h:commandButton value="Entrar" action="#{loginBean.logged}" id="login" />

En este caso, value es el texto que se muestra en el botón, mientras que el atributo action=”#{loginBean.logged}” le está indicando al form que llame al método logged del managed bean loginBean. Ahora, dependiendo del String que devuelva este bean, jsf elegirá uno u otro camino, como configuramos antes en el faces-config. Por lo tanto, es hora de que pasemos a ver

El managed bean es el que se encarga de manejar la lógica de nuestra página jsp, además de ser también quien contiene los atributos (cadenas, valores, listas, etc) que serán accedidos desde la pantalla tanto para mostrarlos al usuario, como para almacenarlos en memoria. Codifiquemos ahora un managed bean muy simple para nuestro ejemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public class LoginBean {
 
    private String userName;
 
    private String password;
 
    public String logged() {
 
        if (checkPassword(userName, password))
            return "success";
        else
            return "failure";
    }
 
    public setUserName(String userName) {
	this.userName = userName;
    }
 
    public String getUserName() {
	return userName;
    }
 
    public setPassword(String password) {
	this.password = password;
    }
 
    public String getPassword() {
	return password;
    }
}

En este managed bean simplemente tenemos un método llamado logged, además de los atributos userName y password con sus respectivos get/set, de modo que podamos acceder a ellos desde la interfaz. El método del ejemplo es bastante sencillo, sólo “chequea” el nombre de usuario y la contraseña (usando el método checkPassword, el cual no es necesario implementar para este tutorial), devolviendo luego un String que será el que le indique a JSF que camino tomar según lo especificado por nosotros en el faces-config.xml. Por lo tanto si el nombre de usuario es válido se redigirá a la página logged.jsp, mientras que en caso de no serlo será redirigido a loginerror.jsp.

Creo que esto será todo por ahora. La idea de este tutorial es ser lo más simple y conciso posible, pero cualquier duda que tengan o si necesitan que sea más extenso en ciertos temas, no duden en decirlo en los comentarios. Ya veremos que nos depara la próxima entrega de este tutorial (esperemos que no se demore tanto como esta).

La cosa es así:

Cuando se usa un Modal Panel de Richfaces para mostrar un formulario de JSF, al ocurrir un error de validación, en vez de mostrarnos los mensajes que hayamos puesto, el Modal Panel (MP) se cierra sin más, lo cual no es ni de cerca el comportamiento que queremos. Si llegamos a abrir de nuevo el MP, podremos ver que los mensajes en realidad habían aparecido, pero al ocultarse el contenedor no pudimos verlos. Cuando pregunté a José Google acerca de esto, me dió la siguiente respuesta:

Keep Rich-Faces modal panel open when form validation errors occur

de la cual podemos extraer aún más soluciones al problema: una en la wiki de JBoss y otra en los foros de JBoss, ambas bastante similares en su forma de resolverlo.

La idea de estas dos últimas soluciones se basa en crear una función de JavaScript que se fije si el form tiene errores, mientras que la primera realiza algo similar utilizando un método del managed bean para verificar esto, e insertando este valor (booleano) en un hidden input.

Ahora, con tantas vueltas que dan estos muchachos ¿No se preguntan ustedes si no existe una forma más sencilla de realizar esto? ¿No debería ser esta forma aparte de sencilla, rápida y lógica? Pues la respuesta es que existe, y es totalmente sencilla, rápida y lógica.

Luego de pelear un rato con la opción de la wiki (la segunda de las tres que puse antes), y de darme cuenta de que tenía un comportamiento algo errático, comprendí que la solución real estaba en usar un botón de a4j como submit del form que haga un reRender del mismo, y no toda esa parafernalia de “un botón que llama a una función en JS que se fija si hay errores y entonces muestra mediante ajax el mensaje y sino le hace un hide al panel” . Como podrán apreciar a continuación, la solución que ofrezco es mucho más sencilla y lógica que las que había encontrado, e incluso me parece mucho más correcta. A pesar de esto, para ser sincere no he probado de cambiar diversos factores, ya sea poner un form a4j o cambiar algo en otros fields, pero lo importante es el botón a4j y el reRender, esa es la solución real. Ahí les va el ejemplo:

1
2
3
4
5
6
7
8
9

<h:form styleClass="form" id="loginForm">
	<h:outputText value="Nombre de usuario" styleClass="username" />
	<h:inputText value="#{loginBean.userName}" required="true" id="usernameInput" size="20" />
        <br />
	<h:message for="usernameInput" styleClass="error" /><br />
 
	<a4j:commandButton value="Entrar al sistema"
		reRender="loginForm" action="#{loginBean.logged}" styleClass="loginbutton" /><br />
</h:form>

Noten que el a4j:commandButton sólo hace reRender del form, con eso debería bastar para que el mismo muestre los mensajes de error en lugar de cerrarse sin más. El problema es que si agregamos un botón de “Cancelar”, al cerrarse el Modal Panel con mensajes de error mostrándose, éstos quedarán “abiertos” cuando mostremos el Modal Panel de nuevo. Si bien esto es fácil de solucionar, sería bueno que si alguien pasa por aquí deje su forma de hacerlo en un comentario, así participan del blog . En caso contrario lo estaré publicando en una próxima entrada. Espero haber sido de utilidad ¡Nos vemos!

Geranio Bigotes

¡Let’s begin!

¿Qué es JSF?

JSF es un framework para aplicaciones J2EE que implementa el modelo MVC.

Características

• Es similar a Struts (un poco más facil de implementar)
• Provee tags HTML propios para interfaces complejas
• Posee sistema de validaciones intrínseco
• Manejo de eventos de los tags
• Acceso simplificado a propiedades de los beans
• Conversión y validación de los campos de formularios
• Configuración centralizada mediante archivos (XML)
• Definición simple de controladores y beans (a diferencia de Struts)
• Permite crear componentes de GUI personalizados

Desventajas

• Poca documentación (aquí es donde pondré mi granito de arena)
• Los validadores no son tan completos como en Struts. Esto se puede solucionar fácilmente con validadores propios (JSF da una forma bastante intuitiva de crearlos) o si no gustas de trabajar tanto, podrías usar los validadores de MyFaces.
• No tiene validación del lado del cliente. Esto se puede remediar usando el framework Shale, pero pienso que, a menos que necesites hacer una validación en la que realmente se note la diferencia al hacerse en el servidor y no en el cliente, no necesitarás más de lo que JSF ofrece.
• No soporta GET, lo cual da cierta seguridad, pero quita flexibilidad y en algunos casos “direccionabilidad”, lo cual puede ser muy molesto.

Como habrán podido apreciar en esta breve descripción de características y desventajas de JSF, la idea es básicamente ser una opción a Struts, pero más flexible (en algunos aspectos) y con interesantes opciones que ésta no ofrece. Yo he trabajado con ambos frameworks y, más allá de ciertos dolores de cabeza que me ha dado (y quizás aún lo siga haciendo) elijo JSF antes que Struts. Si estás realizando algún proyecto web con Struts, lo recomendable es seguirlo con ese framework; pero si estás a punto de empezar con uno y aún no te decides, la opción es JSF, por lo menos desde mi humilde punto de vista.

Bien, espero que a alguien le sirva esto si está a punto de comenzar con JSF. No dejen de pasar por aqui en los próximos días, ya que empezaré con las “clases” en serio: Cómo instalar y configurar JSF.

Hasta la próxima!