Archivo de Autor

rich:element una forma de obtener componentes jsf sin preocuparse por los id

4 Marzo 2009

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.

Performance: Uso de @Create

13 Febrero 2009

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.
» Leer más: Performance: Uso de @Create

Carga dinámica de combos usando JSF y richfaces

28 Enero 2009

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.

» Leer más: Carga dinámica de combos usando JSF y richfaces

Pop up windows en las aplicaciones web

13 Enero 2009

Introducción

Las ventanas Pop up siempre han sido un problema en el desarrollo de aplicaciones web, las que proporciona el browser son poco prácticas al ser mini ventanas que se abren de manera separada a la aplicación, en un browser independiente y que no comparten información de manera natural. (Solamente mediante javascript).

Además recientemente éstas han sido utilizadas como una manera de spam publicitario al activarse al momento de ingresar a la página web, lo que hace que la navegación sea realmente molesta. Dada esta situación los browser decidieron desarrollar sistemas que bloqueen los Pop ups de toda aplicación sin importar si estos eran relevantes o no.

Es por esto que multiples frameworks de javascript como yui, ext, richfaces (aunque no es de javascript tambien provee Pop up windows) han desarrollado Pop up windows basados en un div flotante y que son bastante útiles.

» Leer más: Pop up windows en las aplicaciones web

Integración continua en proyectos de desarrollo

1 Diciembre 2008

El siguiente artículo trata de un nuevo concepto que ha empezado a hacerse popular para el desarrollo de proyectos, sobre todo los que están basados en metodologías ágiles.

¿Qué es Integración continua o Continuous integration?

Según Martin Fowler, escritor de libro “Continuous integration – Improving software quality and reducing risk”, el concepto de integración continua se define como sigue:

“Es una práctica de software donde los miembros del equipo de trabajo integran su código de manera frecuente, dando así multiples integraciones por día. Donde cada integración forma parte de un Build (Integración, Construcción, Pruebas, Despliegue, entre otras cosas). ”

El proceso normal que se sigue en un esquema de trabajo CI es como sigue:

  1. Los desarrollares envían sus modificaciones al controlador de versiones (SVN, CVS, etc).
  2. El Servidor de integración continua monitorea el repositorio buscando cambios y ejecuta automáticamente el build.
  3. Una vez finalizado el proceso de build (integración, construcción, pruebas y despliegue) el servidor envía a los reponsables un email con el resultado del proceso (feedback del proyecto).
  4. El servidor realiza el paso 2 continuamente.

Como puede verse el proceso es relativamente simple pero en muchos proyectos no se realiza ésto que es tan elemental y que a la larga mejora el proceso de desarrollo y evita problemas.

Las ventajas de usar este esquema de trabajo:

  • Los problemas de integración son detectados rápidamente y pueden ser corregidos con la misma celeridad, no hay porque integrar 1 vez al mes y estar corriendo contra el reloj para detectar problemas.
  • Código que rompa el build es detectado automáticamente al tener un feedback automático.
  • Las pruebas unitarias corren cada vez que se ejecuta el build lo cual permite que el desarrollador pueda darse cuenta rápidamente de cualquier error en su código.
  • Existe un mecanismo de despliegue automatizado donde el código producido puede ir a parar a los distintos servers (development server, testing server, production server).

Algunos CI servers open source que se pueden utilizar son:

Algunos CI server pagados que se pueden usar son:

Antartec usa integración continua

Antartec se encuentra en el proceso de implementar un servidor CI para mejorar el proceso de desarrollo de todos nuestros proyectos, para lo cual se realizó la siguiente evaluación:

  • Actualmente en Antartec utilizamos la siguiente combinación para el desarrollo Maven y Subversion.
  • El Servidor CI en evaluación es Hudson.
  • El repositorio de dependencias en evaluación es Hudson ya no es necesario implementar un servidor de dependencias por separado puesto que Hudson ya lo trae incluido.
  • Los Servidores de aplicaciones para dev, test, prod dependiendo del tipo de proyecto pueden ser Tomcat, JBoss, Apache, etc.

La arquitectura propuesta

Basado en el trabajo realizado por Henry Carrión, miembro de Antartec, sobre Integración continua la arquitectura planteada es la siguiente:

Arquitectura planteada según el esquema CI

Arquitectura planteada según el esquema CI

Resultados a obtener

  • Control de cambios
  • Monitoreo constante
  • Integración de procesos
  • Retroalimentación
  • Gestión de dependencias
  • Proceso de desarrollo en base a Métricas
  • Finalmente disminuir el tiempo de desarrollo requerido para cada proyecto

Siendo este último punto el más importante dentro de esquema de trabajo de Antartec.

A manera de conclusión

El concepto de Integración continua es una forma de desarrollo de software que mejora el proceso y puesta en producción del producto desarrollado, mediante la aplicación de herramientas de automatización y mejora continua del proceso.

En Antartec se espera con este sistema mejorar nuestros procesos y tiempos de desarrollo  del software producido.