Escribo este post para todos los que alguna vez sufrieron buscando un ejemplo claro y simple de como crear un combobox en base a un Enum en JSF y Seam.

La documentación de Seam (tan clara como el agua) nos nuestra el siguiente ejemplo:

<h:selectOneMenu value="#{person.honorific}">
<s:selectItems value="#{honorifics}" 
                       var="honorific" 
                       label="#{honorific.label}" 
                       noSelectionLabel="Please select" />
   <s:convertEnum />
</h:selectOneMenu>

Donde solo muestran el ejemplo puntual sin dar mayor detalle.
Googleando un poco encontré la siguiente página web donde se dan el trabajo de explicar de una manera sencilla como crear el combobox.

En esa página se muestra el siguiente ejemplo:

XHTML:

<h:selectOneMenu id="marketStatus" 
                 value="#{person.status}"
                 required="true">
    <s:selectItems value="#{enumLists.statusArray}" 
                   var="status"
                   label="#{status}"
                   noSelectionLabel="Select a status..."/>
    <s:convertEnum/>
</h:selectOneMenu>

ENUM:

@Name("enumLists")
@Scope(ScopeType.STATELESS)
public class EnumLists {
   public Status[] getStatusArray() {
     return Status.values();
   }
}

Como se puede ver en el ejemplo han expuesto el Enum como un Seam bean stateless y retornando la lista de valores con status.values().
Para poner un label a cada opción utilizan el toString() del Enum dado que en label colocan label=”#{status}”

Como pueden ver hacer un combobox basado en un Enum es bastante sencillo y útil.

Sin posts relacionados.

El día de hoy se celebra el día mundial del blog, esto a raíz del parecido entre la fecha 31 de agosto (3108) y la palabra Blog. El movimiento de los blogs ha ido creciendo año tras año y con el tiempo los bloggers se han sumado a publicar sus sitios preferidos.

Es por ello que el día de hoy el equipo que escribe en Desarrollo Web ha dedicado unas cuantas horas a seleccionar y publicar nuestros blogs preferidos. Es así como -siguiendo la tendencia- nos gustaría contribuir con un listado.

Algunas de estas publicaciones son de Desarrollo Web, otras son de temas genéricos pero a la vez recomendables.

• joelonsoftware de Joel Spolsky.
  Tiene muy buenos posts sobre el desarrollo en general y últimamente sobre sus proyectos personales.
• CSSBlog de Pedro Corchero Murga.
  Lo encontramos hace poco y nos ha ayudado muchísimo ahora que algunos de los miembros del equipo están revisando temas avanzados de CSS.
• Coding horror de Jeff Atwood.
  Sus posts más recientes hacen alusión frecuente a la psicología de los programadores.
• Sinergia sin control de Ender Wiggins.
  Es un blog de un comic para frikis muy divertido.
• On Startups de Dharmesh Shah.
  Lo llevamos seguimos hace un tiempo y consideramos que se trata de un buen blog sobre negocios.

Si desean compartir otros blogs que suelen visitar pueden hacer comentarios sobre sus blogs preferidos.

Sin posts relacionados.

Hace algunas semanas en Antartec se nos encargó desarrollar una aplicación web piloto, ésto no tendría mucha novedad y/o relevancia como para escribir un post sobre ello, sin embargo el objetivo planteado lo hizo particularmente interesante.

El reto en esta aplicación fue desarrollar una web que se comporte como una aplicación nativa de iPhone y que le permita a los usuarios ingresar información en tiempo real al sistema sin encontrarse frente a un computador.

Nuestros esfuerzos se concentraron en expandir nuestro actual framework basado en JSF y SEAM para que soporte el formato iPhone; nuestras investigaciones preliminares dieron frutos y encontramos varios frameworks para simular la apariencia de interfaces nativas en iPhone tales como iUI y UiUI (Universal).

iUI desarrollado por Joe Hewitt es un framework bastante maduro que agiliza la construcción de aplicaciones al manejar las vistas, eventos, peticiones y estilos; sin embargo tiene algunas cosas que no son de mi agrado, como por ejemplo:

• Su funcionamiento está dado por el intercambio de vistas o pseudo páginas que se encuentran definidas en un solo documento HTML y mediante manipulación DOM se muestran o se ocultan, para el caso particular de cargar una vista dinámica ésta tiene que ser obtenida por AJAX y reemplazada en la vista apropiada (Ésto no tiene nada de malo pero no se ajusta 100% al ciclo de vida natural de JSF).
• La simulación de las transiciones entre vistas que se utilizan en las aplicaciones nativas de iPhone se muestran con saltos bastante antinaturales, ésto se debe a que utiliza los efectos de CSS3 para realizar las transiciones. Es una lástima que en el Safari para iPhone estas transiciones se vean bastante mal debido probablemente a la velocidad del procesador de video del equipo.
• Para programar para iUI tienes que aprender la manera en que define vistas, cabeceras, botones etc. Para un proyecto corto, en donde no hay mucho tiempo para aprender, ésto se vuelve un impedimento mas que un beneficio (mi opinión es que mantener un esquema de programación conocido facilita la adopción de la tecnología).

iPhone Universal UI fue otro framework que evaluamos. Desarrollado por Diego Lafuente, se basa en una serie de CSS que simulan la apariencia de las aplicaciones nativas.

Al respetar las convenciones web UiUI se perfilaba como uno de los mejores prospectos para nuestro proyecto dado que podía ser adaptado fácilmente al desarrollo de aplicaciones JSF. Sin embargo, a mi modo de ver tiene una gran desventaja para que sea aceptado por las empresas, tiene una licencia GNU Affero General Public License (GNU AGPL 3) en vez de LGPL que no permite utilizarlo para proyectos con fines comerciales.

Dadas estas circunstancias, decidimos crear nuestro propio framework visual para iPhone que utilice todo el poder de los componentes JSF y el templating de Facelets. En una próxima entrega hablaremos más en profundidad sobre los pormenores del framework.

Sin posts relacionados.

Continuando con nuestro artículo anterior hoy hablaremos sobre el manejo de las dependencias e IDEs con soporte de Maven.

Problemática

Hasta antes de la aparición de Maven el manejo de las librerías JAR que utilizaba cada proyecto se hacía de manera manual, las librerías normalmente eran almacenadas junto con el código fuente para que no se perdieran.

Muchos de los proyectos manejaban el mismo conjunto de librerías sin embargo éstas se duplicaban por seguridad y porque normalmente el arquitecto era la única persona que sabía exactamente qué versión de librerías debían ser incluidas en cada uno.

Maven resuelve la mayoría de los problemas de administración de las librerías (JAR) mediante un repositorio centralizado y un mecanismo para la inclusión de dependencias.

¿Qué es una dependencia?

Una dependencia es una referencia en el POM de la librería que se desea incluir en el proyecto. Por ejemplo si deseamos incluir la librería para el manejo de JUnit debemos declararlo de la siguiente manera:

<dependencies>
  <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.5</version>
  </dependency>
</dependencies>

Como vimos en el artículo anterior los objetos en el repositorio se identifican mediante 3 tags groupId:artifactId:version

¿Cómo se estructura el repositorio de Maven?

Maven maneja 3 niveles de repositorio: local, empresarial, global.

El repositorio local normalmente conocido como .m2 se guarda localmente en nuestra pc (En Windows se almacena en “documents and settings” y en linux en nuestro “home”). Dentro de ella encontramos los JAR, WAR, etc en una jerarquía de carpetas que siguen el mismo concepto groupId:artifactId:version.

Veamos un ejemplo de un repositorio local estándar:

El repositorio Empresarial tiene la misma estructura que el repositorio local con la diferencia que almacena librerías de uso compartido a nivel de red. Los repositorios empresariales normalmente se utilizan cuando se maneja un equipo de desarrolladores que trabaja sobre un conjunto variado de proyectos, los cuales normalmente tienen interdependencia entre ellos y sus librerías.

Los repositorios globales son repositorios públicos que almacenan librerías de uso compartido, como por ejemplo el repositorio mismo de Maven o el repositorio público de JBoss o maven central.

Cuando el proceso de compilación busca las dependencias del proyecto lo primero que hace es buscarlas en el repositorio local, si no las encuentra recurre a sus repositorios empresariales (definido en un archivo .settings.xml) o de red y en caso de no encontrar ahí los JAR necesarios los busca en los repositorios globales.

Es importante notar que una vez ubicado un JAR en alguno de los repositorios externos Maven inmediatamente lo descarga al repositorio local por lo que si uno desea que siempre se actualice el JAR de los repositorios externos debe incluir –U en el comando (ejemplo mvn clean install –U ).

El uso de repositorios Empresariales está íntimamente ligado al uso de la metodología de integración continua por lo que les recomiendo leer la entrada Integración continua.

Ámbito de las dependencias

Existen seis ámbitos en los que una dependencia puede ser declarada limitando así su transitividad:
Compile, es el ámbito por defecto. Las dependencias están disponibles en el proyecto y en sus proyectos dependientes.
Provided, se espera que el JDK, la aplicación o el contenedor provea la dependencia.
Runtime, la dependencia no es requerida en tiempo de compilación pero sí para la ejecución.
Test, son dependencias que son requeridas solo cuando se compila y ejecuta los test.
System, similar a provided pero se le debe indicar el jar que contiene la dependencia
Import, (a partir a la version 2.0.9) solo es usado en una dependencia del tipo POM en la sección . Indica que el POM utilizado debe ser remplazado con las dependencias que éste tenga en su sección

Cómo usar maven en Netbeans

En Antartec usamos Netbeans como la plataforma por defecto para el desarrollo de aplicaciones web al proveer de manera integrada la mayoría de componentes necesarios para nuestro trabajo.

Pasos para trabajar en Netbeans con Maven

1. Instalar Netbeans (Lo pueden desargar de www.netbeans.org)
2. En el menú seleccionar Herramientas – plugins
3. En la sección “Plugins disponibles” seleccionar el plugin Maven y hacer clic en Instalar.
4. Reiniciar el netbeans, con eso netbeans reconoce y permite crear proyectos maven desde cero.

Enlaces relacionados

• Maven en detalle – Parte 1
• Maven en detalle – Parte 2

Continuando con nuestro artículo anterior analizaremos la estructura del proyecto y el POM, base de todo proyecto Maven.

La estructura del Proyecto

Dependiendo del tipo de proyecto se pueden tener diferentes estructuras, sin embargo las estructuras más conocidas son la JAR y la WAR.

Veamos la estructura de una aplicación JAR:

Veamos la estructura de una aplicación WAR:

Como puede verse las estructuras son parecidas con la diferencia que la estructura WAR tiene la sección webapp donde irán todos los files jsp, xhtml, html, etc.

En el directorio resources van files de configuración así como el messages.properties.

El POM (Project Object Model)

El POM file es el archivo XML de configuración de cualquier proyecto Maven, en él podemos encontrar información sobre la versión y las dependencias del proyecto así como cualquier otra configuración personalizada para ese proyecto.

El contenido del POM generado después de ejecutar el comando lo podemos ver a continuación:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.antartec.app</groupId>
   <artifactId>my-test</artifactId>
   <packaging>jar</packaging>
   <version>1.0-SNAPSHOT</version>
   <name>Maven Quick Start Archetype</name>
   <url>http://maven.apache.org</url>
   <dependencies>
      <dependency>
           <groupId>junit</groupId>
           <artifactId>junit</artifactId>
           <version>3.8.1</version>
           <scope>test</scope>
      </dependency>
   </dependencies>
</project>

Veamos los tags más importantes:

<groupId> El id del grupo al que pertenece el proyecto.
<artifactId> El id del artifact o proyecto (en la mayoría de los casos el nombre del proyecto).
<version> La versión del artifact en el grupo especificado.
<dependency> Aquí se colocarán todas las dependencias del proyecto.

El POM requiere que estos valores estén definidos ya que ésta es la manera en que Maven los identifica dentro de su repositorio.

Ej. groupId:artifactId:version com.antartec.app:my-test:1.0-SNAPSHOT

Si no se especifica algunos de los tags (packaging,  name,  url) maven usan los valores por defecto heredados del super POM del cual heredan todos los proyectos (hablaremos sobre la herencia más adelante).

Construyamos el proyecto

Ejecutando el siguiente comando se construye el proyecto:

mvn clean install

A diferencia del comando archetype:create este comando es de una sola palabra que especifica la fase que debe ejecutarse. Una fase corresponde a un paso del ciclo de vida de maven. Por ejemplo

mvn compile

Ejecutará las siguientes fases:

validate
generate-sources
process-sources
generate-resources
process-resources
compile

Existe muchas fases en Maven sin embargo listo las más utilizadas a continuación:

• validate – valida que el proyecto es correcto y tiene toda la información necesaria.
• compile – compila el código fuente.
• test – compila el código y ejecuta los unit test correspondientes. Sin embargo no es requisito para que el proyecto sea desplegado.
• package – toma el código compilado y lo empaqueta en un formato distribuible como JAR o WAR.
• integration-test – Despliega el proyecto si es necesario en ambiente de pruebas donde se puedan correr pruebas de integración.
• verify – ejecuta cualquier verificación para cumplir los parámetros de calidad.
• install – instala el jar o war en el repositorio local para que otras aplicaciones locales la puedan usar.
• deploy – copia el jar o war a un repositorio remoto para que pueda ser usado por otro desarrollador o proyecto.

Si desean ver la lista completa de fase las pueden encontrar en lifecycle

Para un desarrollo local bastará con utilizar mvn clean install.

En nuestra siguiente entrega hablaremos sobre el manejo de las dependencias y como usar el proyecto junto con nuestro IDE favorito.

Enlaces relacionados

• Maven en detalle – Parte 1
• Maven en detalle – Parte 3

En esta ocasión trataré sobre el uso del componente tabPanel de RichFaces usándolo con funciones JavaScript para dos casos en particular:

• Hacer el cambio de tabs.
• Verificar si un tab está activo.

El tabPanel presenta 3 maneras para realizar el cambio de un tab a otro mediante el atributo switchType:

• client (se carga la información de todos los tabs).
• ajax (se carga la información mediante ajax, cada vez que se entra al tab).
• server (se carga la información cada vez que se entra al tab, actualizando toda la página).

Antes de comenzar, como nota importante, he probado esta forma de usar el tabPanel con las versiones 3.2.1 y la 3.3.0.GA de RichFaces.

Para todos los ejemplos utilizaré el código siguiente:

<h:form id="miFormulario" >
 
  <!-- para los casos ajax y server switchType tendrá los valores 'ajax' y 'server' respectivamente -->
  <rich:tabPanel id="testTabPanel" switchType="client" >
 
    <rich:tab id="tabUno" label="Tab Uno" >
      <!-- contenido del tab uno -->
    </rich:tab>
 
    <rich:tab id="tabDos" label="Tab Dos" >
      <!-- contenido del tab dos -->
    </rich:tab>
 
  </rich:tabPanel>
 
</h:form>

1. Cambio de tabs:

Para realizar el cambio de tabs, se obtendrá mediante JavaScript el elemento cuyo id tenga la foma <id del tab>_shifted, así:

function irAlTabUno() {
  // se obtiene el elemento:
  var tabUno = document.getElementById('miFormulario:tabUno_shifted');
  // esta es la línea que realizará el cambio de tab
  // si el tab se encuentra activo entonces no hará nada:
  tabUno.onclick();
}
 
function irAlTabDos() {
  document.getElementById('miFormulario:tabDos_shifted').onclick();
}

El ‘truco’ es obtener mediante JavaScript el elemento correcto (al cual hacerle onclick), lo que hace RichFaces es crear un HTML <table> dentro de la celda que contiene la pestaña con el mismo id que le dimos al tab pero concatenándole ‘_shifted’.

Existe una manera en particular para hacer el cambio pero sólo si se encuentra en modo ‘client’, la cual es usando una de las funciones del archivo tabPanel.js de RichFaces:

function irAlTabUno() {
  RichFaces.switchTab('miFormulario:testTabPanel', 'miFormulario:tabUno', 'Tab Uno');
}
 
function irAlTabDos() {
  RichFaces.switchTab('miFormulario:testTabPanel', 'miFormulario:tabDos', 'Tab Dos');
}

O usando rich:clientId()

function irAlTabUno() {
  RichFaces.switchTab('#{rich:clientId('testTabPanel')}', '#{rich:clientId('tabUno')}', 'Tab Uno');
}
 
function irAlTabDos() {
  RichFaces.switchTab('#{rich:clientId('testTabPanel')}' ,'#{rich:clientId('tabDos')}', 'Tab Dos');
}

Donde la función RichFaces.switchTab() recibe 3 parámetros: el id del tabPanel, el id del tab al cual queremos ir, y el label del mismo tab destino.

2. Verificar si un tab está activo:

Aquí también usaremos una de las funciones del archivo tabPanel.js de RichFaces:

function estaActivoTabUno() {
  return RichFaces.isTabActive('miFormulario:tabUno_lbl');
}
 
function estaActivoTabDos() {
  return RichFaces.isTabActive('miFormulario:tabDos_lbl');
}

Igual que en el caso anterior de cambio de tabs, el ‘truco’ es usar el HTML <td> que crea RichFaces con el mismo id que le dimos al tab pero concatenándole ‘_lbl’. Entonces llamamos a la función RichFaces.isTabActive() que recibe como parámetro este id.

Conclusión:

Normalmente cambiar de tab es tan sencillo como hacer clic en el tab al cual queremos cambiar, y conocer el tab activo se realiza mediante el atributo ’selectedTab’ del rich:tabPanel (con un backing bean de por medio). Por eso esta manera de hacer ambas cosas mediante JavaScript es para casos muy particulares como por ejemplo, verificar que no se realice el cambio de tabs sin antes haber validado/guardado la información de cada tab independiente (cada tab posee un formulario), previa pregunta de confirmación al usuario con un javascript:confirm(‘…’).

Sin posts relacionados.

Comenzamos la saga Maven compuesta por una serie de artículos en donde detallaremos como instalar, construir, desplegar un pequeño proyecto piloto.

En artículos anteriores hemos hablado sobre las ventajas de Maven y como es que éste encaja dentro la de estructura de integración continua en el desarrollo de proyectos por lo que pasaremos directamente a los detalles.

Empecemos por instalar Maven

Tenemos que ir al sitio web de la Maven y descargar la última versión (http://maven.apache.org/download.html),  es necesario contar con el JDK previamente instalado.

Seguimos las instrucciones de la página para configurar las variables de entorno correspondientes para máquinas con Windows o Linux.

Una vez instalado, construiremos nuestro primer proyecto

Una vez instalado maven en nuestro computador podemos empezar por construir nuestro primer proyecto de prueba al cual llamaremos app-test.

Ejecutamos el siguiente “Archetype” para crear un jar en la línea de comandos:

mvn archetype:create
-DarchetypeGroupId=org.apache.maven.archetypes
-DgroupId=com.antartec
-DartifactId=app-test

Los archetype son simples plugins de maven, uno de ellos es el archetype create, el cual permite crear un proyecto base al proporcionar la plantilla del mismo.

El archetype create recibe una serie de parámetros los cuales son:

• archetypeGroupId, usar este parámetro es una manera abreviada de crear un proyecto de tipo jar, sin embargo cuando se usan archetypes creados por uno mismo se tiene que especificar los tres parámetros de todo archetype (groupId, artifactId,version) de la siguiente manera.

mvn archetype:create
-DarchetypeGroupId=<archetype-groupId>
-DarchetypeArtifactId=<archetype-artifactId>
-DarchetypeVersion=<archetype-version>
-DgroupId=<my.groupid>
-DartifactId=<my-artifactId>

• groupId, es usado como identificador del conjunto de librerías en este caso hemos usado com.antartec como  nombre para nuestro paquete de librerías.
• artifactId, es usado como identificador particular de una librería en particular.

Si es la primera vez que se ejecuta un comando Maven éste tomará algo de tiempo pues Maven creará el repositorio inicial .m2 y descargará todas las librerías necesarias para construir el proyecto.

Si deseamos crear un proyecto war en vez de un jar ejecutaremos el siguiente “Archetype” en la línea de comandos:

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-webapp
-DgroupId=com.antartec.app
-DartifactId=webapp-test

En este caso hemos ejecutado un archetype distinto que contiene la plantilla de un proyecto web.

En el siguiente artículo analizaremos la estructura del POM generado, base de cualquier proyecto Maven.

Enlaces relacionados

• Maven en detalle – Parte 2
• Maven en detalle – Parte 3

Cuando trabajamos con JSF tenemos que tener cuidado con los ids que asignamos a cada componente, dado que estos deben ser únicos.

JSF y otras librerías, para prevenir problemas en este sentido, siguen las siguientes reglas:

1. Cuando no se asigna un id de manera explícita a un elemento se le genera un client id único.
2. A todos los client ids (autogenerados o fijos) le antepone los client ids de los componentes padres, por ejemplo un inputText que se encuentre dentro de un form tendría un client id de la siguiente forma: nombreForm:nombreInputText.
3. Componentes como a4j:repeat van incluso más alla,  generando client ids  con esta estructura nombreForm:nombreRepeat:indice:componente.

Antes de la última versión de rich faces (http://www.jboss.org/jbossrichfaces/downloads/) teníamos el problema de tener que estar pendientes de los client id, por ejemplo para obtener un elemento teníamos que escribir algo como esto:

document.getElementById(“formName:elementName”)

Sin embargo rich proporciona ahora 4 métodos muy interesantes para obtener referencias a los componentes desde javascript:

• rich:clientId(‘id’) retorna el client id compuesto del componente JSF
• rich:element(‘id’) es una contracción de document.getElementById(#{rich:clientId(‘id’)})
• rich:component(‘id’) es una contracción de #{rich:clientId(‘id’)}.component
• rich:findComponent(‘id’) devuelve una instancia de UIComponent tomando el id como parámetro.

Veamos un ejemplo:

<script>
function getLinkAndDoClick() {
#{rich:element('linkid')} .onclick();
}
</script>
 
<h:form>
<a4j:commandLink id=”linkid” value=”Haz click aqui” action=”#{somebean.someAction()}”/>
</h:form>

De esta manera se puede obtener referencias a los componentes JSF sin tener que estar preocupándose cómo sus client id son generados.

Sin posts relacionados.

En este post me gustaría hacer una pequeña contribución al post “Performance: ¿Por qué usar @Factory en vez de getters?” de Seam City sobre el uso de @Factory para la obtención de listas.

En el post se menciona que los valores obtenidos por EL no se guardan en cache y ésto es un problema sobre todo cuando se acceden a listas que son cargadas desde la base de datos.

Para resolver el problema el post plantea 2 opciones:

Por patrón de carga lazy loading

@Name("userManager")
public class UserManager {
  private List list;
 
  public List getUserList() {
    if (this.list == null) {
      this.list = createUserList();
    }
    return list;
  }
}

Y una mejor manera utilizando las anotaciones @Out y @Factory

 
public class UserManager {
 
  @Factory(value = "userList", scope = ScopeType.PAGE)
  public List getUserList() {
     if (this.list == null) {
       this.list = createUserList();
     }
     return list;
  }
}

Sin embargo existe una tercera solución que es bastante más clara y sobre todo sigue la convención con respecto a la creación de objetos y es utilizar la anotación @Create

El código es el siguiente:

 
@Name("userManager")
@Scope(ScopeType.PAGE)
public class UserManager implements Serializable {
 
  private List<User> list;
 
  @Create
  public void loadInitData() {
     this.list = createList();
  }
 
  public List<User> getList() {
    return list;
  }
 
   public void setList(List<User> list) {
     this.list = list;
   }
}

La anotación @Create nos permite declarar que un método se ejecute al momento que un componente es creado. Momento apropiado para cargar toda la información que sólo debe ser obtenida una vez.

La anotación @Scope(ScopeType.PAGE) nos permite establecer un contexto para el componente de seam, en este caso que el componente exista mientras la página esta activa. Se pueden utilizar otros contextos como por ejemplo Conversation o Session, sin embargo no es recomendable usar el contexto session a menos que sea estrictamente necesario pues sin una adecuada adminstración la memoria requerida por aplicación puede dispararse.

A modo de conclusión

Es una buena práctica centralizar la información de carga estática en un solo método y combinado con el scope Page mejor, pues el uso de memoria en el servidor es mínimo.

Sin posts relacionados.

La carga dinámica de un combo basado en la selección de un combo previo es un problema relativamente clásico y que ha sido abordado de distintas maneras a lo largo del tiempo.

En este post queremos mostrarles como es que nosotros abordamos el tema usando componentes JSF y de Richfaces para resolver el problema.

Para este ejemplo usaremos 2 entidades (Ciudad y Distrito) donde una ciudad tiene múltiples distritos asociados y para el caso práctico asumiremos que ambas solo tienen un id y un nombre.

@Entity
@Table(name = "CIUDAD")
public class Ciudad implements Serializable {
 
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "ID_CIUDAD", nullable = false)
    private Integer idCiudad;
 
    @Length(max=45)
    @Column(name = "NOMBRE",length=45)
    private String nombre;
}
 
@Entity
@Table(name = "DISTRITO")
public class Distrito implements Serializable {
 
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "ID_CIUDAD", nullable = false)
    private Integer idDistrito;
 
    @Length(max=45)
    @Column(name = "NOMBRE",length=45)
    private String nombre;
}

Además tendremos un managed bean de JSF llamado testBean que nos servirá para almacenar la información temporal de la página.

@Name("testBean")
@Scope(ScopeType.CONVERSATION)
public class TestBean implements Serializable {
 
    private Integer idCiudad = -1; //Omitimos sus gets y sets
    private Integer idDistrito = -1;//Omitimos sus gets y sets
 
    public  Map<String,Integer> getCiudadList() {
        String query = "select new map(nombre as nombre, idCiudad as idCiudad) " +
                "from Ciudad order by nombre";
        return uiUtils.getComboBox(query, "nombre", "idCiudad");
    }
 
    public  Map<String,Integer> getDistritoList() {
        String query = "select new map(d.nombre as nombre, d.idDistrito as idDistrito) " +
                "from Distrito d where d.ciudad.idCiudad = " + idCiudad + " order by nombre";
        return uiUtils.getComboBox(query, "nombre", "idDistrito");
    }
 
}

Solo para simplificar el asunto el método getComboBox hace una consulta a la Base de datos y genera una estructura Map&ltString,Integer>

El signature del método es:

public  Map<String,Integer> getComboBox(String query, String value, String key)

El código que corresponde a la parte de JSF se los presento a continuación:

<h:selectOneMenu value="#{testBean.idCiudad}" style="width:200px;">
  <f:selectItem itemLabel="#{messages['comun.selectOneMenu.seleccione']}" itemValue="-1" />
  <f:selectItems value="#{testBean.cuidades}"/>
  <a4j:support event="onclick" reRender="distritosPanel"/>
</h:selectOneMenu>
<a4j:outputPanel id="distritosPanel">
  <ui:fragment rendered="#{testBean.idCiudad ne -1}">
    <h:selectOneMenu value="#{testBean.idDistrito}" style="width:200px;">
       <f:selectItem itemLabel="#{messages['comun.selectOneMenu.seleccione']}" itemValue="-1" />
       <f:selectItems value="#{testBean.distritos}"/>
    </h:selectOneMenu>
  </ui:fragment>
</a4j:outputPanel>

Como pueden ver es muy sencillo, cada combo tiene dos propiedades importantes, la primera es la que almacenará el resultado de la selección en este caso idCiudad y idDistrito, la segunda es la lista de opciones del combo el cual se obtiene de una propiedad List<SelectItem>, esta lista es generada en el managed bean haciendo consultas a la base de datos.

Los componentes JSF por default no tienen soporte AJAX, lo que significa que tendrían que hacer un submit cada vez que quisieran recargar una sección de la página, es por esto que utilizamos el tag a4j:support que nos permite darle una naturaleza AJAX al componente JSF.

<a4j:support event="onclick"  reRender="distritosPanel"/>

Como pueden ver al tag a4j:support tiene 2 propiedades, la primera es el evento que dispara la acción, este podría ser onclick, onmouseover, onmouseout, en este caso utilizamos onchange.La segunda propiedad es el parámetro reRender que le dice al componente las secciones de código que deben ser refrescadas una vez que el request AJAX haya terminado.

De esta manera podemos conseguir cargar dinámicamente un combo JSF mediante AJAX.

Más información

• Rich faces Demo
• Tag lib de JSF 1.2

Sin posts relacionados.