Uno de los aspectos más importantes para dominar y hacer uso de una tecnología es tener acceso a buena documentación. En el caso específico de la librería JQuery se cuenta con gran cantidad de información disponible en su sitio web, además de recursos de programadores con ejemplos prácticos de uso.

Sin embargo, la documentación oficial de la herramienta es presentada en páginas independientes, por lo que navegar a través de ellas buscando información específica resulta complicado. Es por ello que quiero compartirles una utilidad que permite encontrar rápidamente mayores detalles de cualquier función de JQuery.

La herramienta, JQuery API browser es accesible de dos maneras: la primera es mediante la aplicación web que utiliza una interfaz AJAX para saltar entre funciones de la librería y la segunda mediante una aplicación de escritorio basada en Adobe Air.

Espero la disfruten tanto como yo lo he hecho.

JQuery es una excelente librería JavaScript que simplifica la manipulación del DOM (Document Object Model) de una página HTML, el manejo de eventos, animaciones y AJAX. Así también, desde hace un tiempo atrás provee una librería de componentes UI que extiende los componentes iniciales de esta librería.

El widget de tipo diálogo es un ventana flotante que tiene un título y contenido (similar a un popup). Este widget resulta ser muy útil para mostrar alertas o formularios que el usuario debe llenar antes de poder continuar. Veamos como lograr lanzar un dialog apenas carga la página

<script type="text/javascript" src="/assets/javascript/jquery-1.4.min.js"></script>
<script type="text/javascript" src="/assets/javascript/jquery-ui-1.8.custom.min.js"></script>
 
<script type="text/javascript">
 
$(function() {
 $("#dialog").dialog();
});
 
</script>
 
<div id="dialog" title="Basic dialog">
        <p>This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.</p>
</div>

Ejemplo tomado de la página web de Jquery

Como puede apreciarse en el código anterior, esta es una solución muy sencilla para hacer un widget dialog; sin embargo, cuando se desarrolla un sistema de mayor complejidad lo ideal es separar las ventanas en múltiples archivos y los diálogos no son la excepción. Una implementación bastante difundida en la web es utilizar un elemento iframe en vez de una etiqueta div para construir el contenido del diálogo. Veamos un ejemplo para que quede más clara la idea.

<script type="text/javascript">
 
$(function() {
        $('a.showPopup').click(function(e) {
            e.preventDefault();
            var $this = $(this);
            var horizontalPadding = 15;
            var verticalPadding = 15;
            $('<iframe id="site" src="' + this.href + '" />').dialog({
                title: ($this.attr('title')) ? $this.attr('title') : 'Site',
                autoOpen: true,
                width: 600,
                height: 300,
                modal: true,
                resizable: false,
                autoResize: true,
                overlay: {
                    opacity: 0.5,
                    background: "black"
                }
            }).width(600 - horizontalPadding).height(300 - verticalPadding);
        });
});
 
</script>
 
<a class="showPopup" href="http://www.google.com" title="Google">

Como puede apreciarse en el ejemplo anterior, se utiliza un pseudo iframe, al cual le asignamos la dirección con el contenido que queremos mostrar en el diálogo. Algunas posibles mejoras a esta idea inicial sería crear una función que permita reutilizar el código en otros enlaces, pero eso se los dejo como tarea.

EDIT:
Respondiendo aun pregunta realizada por un lector estoy agregando una manera de cerrar el diálogo desde el iframe mismo:

<script type="text/javascript">
var refDialog;
$(function() {
...
refDialog = $('<iframe id="site" src="' + this.href + '" />').dialog(...);
...
});
</script>

Dentro del iFrame colocar un link de la siguiente manera:

<a href="javascript:void(0);" onclick="window.parent.refDialog.dialog('close');">close</a>

Hace poco empezamos a probar Django, uno de los frameworks web más populares para el lenguaje Python. Nos gustaría compartir las características que nos han parecido impresionantes y algunas que no nos han gustado.

Lo más impresionante: el sitio de administración

El “admin site”, como le llaman los Djangonautas, es más que un simple scaffolding para el back-end, puesto que construye una interfaz más avanzada.

Django puede deducir información de los modelos para generar automáticamente las páginas de administración de los objetos de negocio, desde donde se realizan todas las operaciones sobre base de datos: lectura, actualización, creación, eliminación, validación, relación con otros objetos, etc. Así, los usuarios administradores puedan agregar contenido al sitio y tenerla lista para mostrar a los clientes finales.

En unos pocos pasos, explicados en la parte 2 del tutorial, Django ofrece:

• El widget correcto a utilizar (combobox, textbox, textarea, etc) para cada campo del objeto de negocio en el formulario de creación y edición.
• Atajos inteligentes para los campos: calendarios para las fechas, vínculos de “hoy” y “ahora” para fechas y horas.

Ejemplo de formulario, con validaciones (*)

• Listas desplegables para escoger objetos relacionados (a través de llaves foráneas), con un atajo especial para crear un nuevo objeto relacionado en una ventana pop-up en caso éste no exista todavía.
• Validación de cada uno de los campos por tipo de dato y longitud.

Ejemplo de filtros y campos de búsqueda (*)

• Filtros y criterios de búsqueda para cada objeto, con vínculos de “último mes” y “última semana” para buscar por fecha
• Acciones en masa: seleccionar varios objetos y borrarlos a la vez, cambiarles de estado o cualquier acción definida por el programador
• Historial de acciones por cada usuario

Ejemplo de usuarios, perfiles y roles

• Administración de usuarios, incluyendo perfiles y roles

Una lista bastante larga para un sitio generado automáticamente, ¿no es verdad?

Así, Django nos salva de la tediosa pero infaltable tarea de programar el back-end. Con unas pocas líneas de código, se obtienen páginas listas para mostrar en producción.

(*) Imágenes tomadas del tutorial oficial de Django.

Lo más decepcionante: necesitamos migraciones, ¡urgente!

En Django, un cambio en los modelos no implica un cambio en la base de datos; es decir, el comando ’syncdb’ sólo puede crear tablas, pero no alterar las antiguas.

Los modelos suelen evolucionar con el tiempo, porque cambian los requerimientos o simplemente notamos un error: falta o sobra un campo, o se necesita una tabla extra y una llave foránea. Django no ofrece ningún soporte para estos casos, así que uno se ve obligado a modificar el esquema escribiendo las sentencias SQL a mano. Esto es inconcebible por las siguientes razones:

1. Algunos de los casos mencionados podrían implicar pérdida o inconsistencia de datos. Es responsabilidad del framework estar alerta de estos errores y proteger al desarrollador de ellos, especialmente si se trata de un tema tan sensible.
2. Cada motor de base de datos maneja su propia versión de SQL, así que una modificación manual no serviría universalmente.
3. Una de las tareas de un framework es esconder el lenguaje SQL (es por esto que existen los ORMs).
4. Django debería ser capaz de manejar al menos los casos más sencillos, como agregar una columna.

En Ruby on Rails, el framework web más popular para el lenguaje Ruby, existe el concepto de “migración“: es posible manipular el esquema de datos a través de código en Ruby, ya sea para crear tablas, agregar columnas o insertar datos. Esta facilidad ofrece muchas ventajas:

1. Abstracción del lenguaje SQL; es decir, una migración es útil inclusive si se usan distintos motores de bases de datos (por ejemplo, uno ligero para desarrollo y uno más potente para producción, o si la aplicación se desplegó en más de un entorno, cada uno con sus requerimientos sobre bases de datos).
2. Disponibilidad universal, puesto que las migraciones son archivos que se almacenan en el directorio del proyecto, así que cualquier desarrollador puede acceder a ellas (a través del repositorio) y mantener sincronizada su copia local.
3. Uso automatizado, puesto que las migraciones son código fuente ejecutable. Esto no es posible si se usara un gestor gráfico para interactuar con la base de datos.
4. Historial de versiones de la base de datos, puesto que se crea una migración por cada transacción. Así, es posible deshacer o aplicar un conjunto de cambios sobre la base de datos, lo que equivale a mantener el esquema de datos bajo control de versiones (repositorio). Esto no es posible si se usara un gestor gráfico.

Migración para crear una tabla

Django necesita algo similar con urgencia. Por el momento, lo más recomendable es comenzar a utilizar el sitio de administración inmediatamente después de definir los modelos, para poder notar errores lo antes posible y no tener que lidiar con la evolución del esquema. Naturalmente, los desarrolladores de Django ya han comenzado a discutir opciones para salvar este error.

Conclusión

Django es un framework que ofrece muchas abstracciones de alto nivel que simplifican enormemente la tarea del desarrollo web. El ejemplo más claro es la generación automática del back-end, que ahorra muchas horas de labor tediosa.

La documentación es excelente. La curva de aprendizaje de Django es muy baja gracias a la cantidad de información disponible acerca de él, muy bien redactada y muy completa.

El manejo del esquema de la base de datos es un señor problema. A menos que uno sea un experto en SQL (cosa que la “mala” costumbre de los ORMs hace improbable), seguro se tendrán problemas al hacer cambios a las tablas, inclusive cambios sencillos.

Fuentes

• Tutorial oficial de Django
• Documentación oficial de Django
• “Schema Evolution”, de la wiki de Django
• “Migrations”, de la documentación de Ruby on Rails

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.

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(‘…’).

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.

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.

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> getCiudades() {
        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> getDistritos() {
        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<String,Integer>

El signature del método es:

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

UPDATE:
Me preguntaron que cosa hace el uiUtils, el uiUtils es un seam bean stateless que tiene un método llamado getComboBox el cual devuelve un Map de labels, ids, la función hace un query a la bd que retorna un map con los dos valores.

Otra alternativa a usar un Map es utlilizar una lista de SelectItem, el objeto tiene el siguiente constructor en su modalidad más sencilla:

new SelectItem(Object valor, String label)

Por lo tanto simplemente es iterar sobre el resultado del query y crear los objetos y retornar la lista.
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="onchange" 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="onchange"  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

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.

¿Qué hace que un Pop up window sea realmente útil?

Un Pop up window utilizado dentro de una aplicación es útil en la medida en que pueda cumplir los mismos requerimientos que tendría un Dialog hecho en Java o C#.

Por lo tanto las características que deben tener son:

• Deben poder ser invocados desde cualquier lugar (en este caso desde cualquier página web).
• Ser autocontenibles (que no se necesite registrar información extra para que funcionen).
• En caso que necesiten retornar parámetros, estos debe poder ser obtenidos en la página que lo llamo.
• Una extensión del punto anterior seria que los Pop up window puedan intercambiar información entre ellos.
• Capacidad de recibir parámetros.

Nuestra solución

Hemos planteado nuestra solución de la siguiente manera:

Para cumplir con el primer y tercer objetivo tenemos un objeto javascript que es omnipresente a todas las páginas y se encarga de: crear, mostrar y cerrar los Pop up y además maneja los parámetros de retorno.

Para cumplir con el segundo objetivo el contenido del modal panel esta en otra página web y ésta es mostrada a través de un iframe dentro del modal.

Para cumplir con el quinto objetivo simplemente se los pasamos como parámetros de url a la página dentro del iframe.

Un ejemplo de cómo instanciamos un objeto:

function editarObjeto(id) {
  ManejadorVentanas.mostrar({
   id: 'idPanel',
   titulo: 'Editar objeto',
   src: '/contenido/editarObjeto.xhtml?id=' + id,
   ancho: 500,
   alto: 350,
   callback: refrescarLista
 });
}

Como puede verse la invocación es muy sencilla y solo se requiere tener la página en donde se desarrollará el contenido.

La función de callback permite obtener los parámetros de retorno, de esta manera:

function refrescarLista () {
   var rpta = ManejadorVentanas.obtenerParametros('idPanel')['rptaModal'];
   if (rpta) {
      var valorRetornado = ManejadorVentanas.obtenerParametros('idPanel')['valor1'];
 
      // hacer algo mas.
   }
 }

A manera de conclusión

No importa con que librería de javascript estén trabajando (YUI, JQuery, ExtJS, Dojo, etc) estos principios básicos deben poderse cumplir para poder sacar el máximo provecho de las Pop up windows dentro de una aplicación web.

Este artículo tratará sobre el framework JavaServer Facelets comenzando con una pequeña introducción y luego una descripción básica del uso de templating en una aplicación JSF (JavaServer Faces).

Introducción

JavaServer Facelets es un framework para plantillas (templates) centrado en la tecnología JSF (JavaServer Faces), por lo cual se integran de manera muy fácil. Este framework incluye muchas características siendo las más importantes:

• Tiempo de desarrollo cero de los tags para UIComponents.
• Facilidad en la creación del templating para los componentes y páginas.
• Habilidad de separar los UIComponents en diferentes archivos.
• Un buen sistema de reporte de errores.
• Soporte completo a EL (Expression Language).
• Validación de EL en tiempo de construcción.
• No es necesaria configuración XML.
• Trabaja con cualquier RenderKit.

Desafortunadamente JSP (JavaServer Pages) y JSF no se complementan naturalmente, cuando se usan juntos ambos escriben output al response, pero lo hacen de una manera diferente: JSP crea output ni bien encuentra código JSP (es decir procesa los elementos de la página de arriba a abajo), mientras que JSF dicta su propio re-rendering (ya que su ciclo de vida está dividido en fases marcadas). Facelets llena este vacío entre JSP y JSF, siendo una tecnología centrada en crear árboles de componentes y estar relacionado con el complejo ciclo de vida JSF.

¿Por qué Facelets?

• No depende de un contenedor Web.
• Integrar JSP con JSF trae problemas, además, no se puede usar JSTL (JavaServer Pages Standard Tag Library) con JSF, cosa que Facelets sí provee.
• Facelets provee un proceso de compilación más rápido que JSP.
• Provee templating, lo cual implica reutilización de código, simplificación de desarrollo y facilidad en el mantenimiento de grandes aplicaciones.
• Permite crear componentes ligeros sin necesidad de crear los tags de los UIComponents (es más fácil comparado a crear un componente JSF puro).
• Soporta Unified Expression Language, incluyendo soporte para funciones EL y validación de EL en tiempo de compilación.

Templating

Existen tres maneras de modularizar las páginas y componentes: includes, archivos tag y decorators. Pero primero algo básico de templating:

La página que contendrá al template:

<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:c="http://java.sun.com/jstl/core">
 
  <head>
    <ui:insert name="head"/>
  </head>
 
  <body>
    <div class="body">
      <ui:insert name="body">
        Contenido por defecto
      </ui:insert>
    </div>
  </body>
 
</html>

El template en sí:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:c="http://java.sun.com/jstl/core"
  template="/template.xhtml">
  <!-- nótese el uso del atributo 'template' -->
 
  <ui:define name="head">
    <!-- contenido de la cabecera -->
  </ui:define>
 
  <ui:define name="body">
    <!-- contenido del cuerpo -->
  </ui:define>
 
</ui:composition>

Como puede verse donde uno quiere que se inserte código se usa el tag <ui:insert name=”nombre”/> donde nombre corresponde al identificador de la sección.

Tres maneras de modularizar con Facelets

Esta es la porción de código que se abstraerá para los ejemplos siguientes:

<ui:composition>
  Bienvenido, #{usuario.nombre}
</ui:composition>

• Templating mediante ‘includes’

Este es el método más familiar para modularizar componentes (se le pueden pasar parámetros al ‘ui:include’).

<span id="loginDisplay">
  <ui:include src="/contenido/bienvenido.xhtml" >
   <ui:param name="usuario" value="#{usuarioActual}"/>
  </ui:include>
</span>

• Templating mediante un ‘tag file’

Para esta manera de templating, al tag se le da un namespace, por ejemplo:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:c="http://java.sun.com/jstl/core"
  xmlns:my="http://www.mycompany.com/jsf">
...
  <!-- uso del tag -->
  <my:bienvenido usuario="#{usuarioActual}" />
...
</ui:composition>

¿Cómo especificamos el tag?: en un archivo xml, que es una libreria de tags facelets. Este archivo es cargado automáticamente por Facelets, para ello debe tener la extensión *.taglib.xml y estar ubicado en el directorio especial META-INF.

<facelet-taglib>
  <namespace>http://www.mycompany.com/jsf</namespace>
  <tag>
    <tag-name>bienvenido</tag-name>
    <source>contenido/bienvenido.xhtml</source>
  </tag>
...
  <!-- otros tags -->
</facelet-taglib>

• Templating mediante ‘decorators’

Los decorators se pueden usar de la misma manera que los compositions, pero éstos pueden ser insertados en la página (inline).

El texto anterior se mostrará.
<ui:decorate template="/contenido/bienvenido.xhtml">
  <ui:param name="usuario" value="#{usuarioActual}" />
</ui:decorate>
El texto posterior se mostrará.

Un uso práctico del decorator es cuando no tiene mucho sentido abstraer el componente en un archivo aparte, pero sí usar las ventajas del templating.

A manera de conclusión

El uso de templating trae consigo las ventajas de tener un código ordenado (sobre todo en aplicaciones grandes), fácil de desarrollar y reusar. Uno puede crear componentes o templates que abarcan desde simplemente mostrar texto hasta crear componentes que muestren un checkbox, un input o un dropdown dependiendo de la data del backing bean.