RichFaces, trabajando con tablas (1)

Introduccin

El problema de la gestin de tablas se describe en el siguiente esquema:

La renderizacin de tablas que muestran gran cantidad de datos acarrea varios problemas:

1. Acceso a la base de datos. 2. Almacenamiento de los registros como objetos Java en memoria. 3. Renderizacin de todos los registros en la pgina que ver el usuario en el navegador.

La biblioteca de componentes JavaServer Faces de JBoss llamada RichFaces proporciona varios componentes para el

manejo de tablas avanzado, proporcionando paginacin, ordenacin y filtrado de datos. Estos mecanismos intentan

reducir los problemas de renderizacin provocados por la visualizacin de demasiados elementos en una tabla simultaneamente, este concepto ha sido identificado mediante el punto 3.

Los componentes RichFaces que vamos a utilizar son:

Estos componentes nos permitirn gestionar grandes cantidades de informacin de forma eficiente:

Creando tablas

Introduccin

El componente rich:dataTable permite crear tablas en RichFaces. Este componente es muy parecido al componente

con dos variaciones:

Skinnability: se aplican estilos sobre las tablas de una forma cmoda y sencilla.

Soporte Ajax: este componente es capaz de manejar y generar peticiones y respuestas Ajax.

Tambin existen atributos para la gestin de eventos.

...

Los atributos ms importantes del componente son:

value: la coleccin de datos que se va a mostrar. Se hace referencia a sta mediante lenguaje de expresin.

var: nombre de la variable sobre la que se itera.

...

Importante: se supone que el lector maneja JavaServer Faces, por esa razn, debe estar familiarizado con estos atributos,

el lenguaje de expresin, etc.

El componente rich:column

La definicin correcta de la tabla se hace habitualmente mediante el uso de otro componente llamado column. Como su

nombre indica, permite crear columnas dentro de la tabla. La informacin que muestra cada columna se incluye dentro de ella, anidando otro componente. Por ejemplo, si se quiere mostrar un texto se anidar un componente

...

Las facetas de la tabla

La definicin de ttulo, cabecera y pie de tabla se realiza mediante facetas: header, footer y caption. Como se puede ver en

el ejemplo anterior, se definen cabeceras para cada columna:

...

...

Ejemplo

Se pasa a renderizar una tabla de facturas. stas se encuentran almacenadas en una lista definida en un mbean de

JavaServer Faces (debe estar declarado en el fichero de configuracin de JSF).

...

public class MBean1 {

...

// Lista de facturas que muestra la tabla

public List facturas;

...

}

La clase Factura tiene atributos para cada informacin que se quiere manejar de la factura:

...

public class Documento{

private String concepto;

private String codigo;

private double importe;

...

}

La tabla en la vista se construye de la siguiente forma:

...

...

Paginando tablas

El proceso de paginacin se lleva a cabo mediante el componente . Para realizar la paginacin se

utilizan peticiones Ajax. Este componente debe incluirse dentro del pie de la tabla padre o relacionarla mediante su

atributo for:

- Dentro del pie:

...

...

- Mediante el atributo for: almacena el id de la tabla sobre la que se est actuando.

...

...

En ambos casos se consigue algo de este estilo:

El componente dataScroller genera una barra numerada que permite recorrer todos los elementos de la tabla.

Ordenando y filtrando tablas

La ordenacin de tablas se realiza trabajando con el atributo sortBy asociado a los componentes . Se

muestra a continuacin:

...

El proceso de filtrado se lleva a cabo aplicando sobre las columnas, es decir, los componentes el atributo

filterBy.

...

...

Si se aplican ambos conceptos sobre la misma tabla, se obtiene algo as:

Conclusiones

Los componentes para el manejo de tablas de RichFaces, utilizados de forma estndar, nos permiten mejorar las

prestaciones de nuestras tablas en cuanto al nmero de elementos renderizados en nuestras pginas simultneamente,

pero en ningn caso, nos permite reducir el nmero de objetos almacenados en memoria ni el tipo de consultas que

realizo sobre la base de datos. En prximos arttulos se describe este proceso de mejora.

RichFaces, trabajando con tablas (2)

Introduccin

Se quiere trabajar con tablas paginadas que NO tengan que guardar en memoria TODOS los objetos de la tabla, estn siendo mostrados en pantalla o no. De esta forma se optimiza la memoria necesaria para la aplicacin.

El modelo presentado en el artculo "RichFaces, trabajando con tablas (1)" maneja un conjunto de datos mediante una

lista Java (se modela mediante la interface List). De tal forma que, independiente de la paginacin que se est aplicando, todos los objetos de la tabla se encuentran cargados en memoria. Esto, en muchas ocasiones, no es viable.

La solucin que se plantea en este artculo permite almacenar en memoria SLO los objetos que se estn utilizando en

cada momento. Como ya se ha comentado anteriormente, no se trabaja con una implementacin de la interface List. El modelo va a evolucionar para trabajar de una forma ms sofisticada:

...

El modelo ser una clase que hereda de SerializableDataModel. Se modifica, a continuacin, el ejemplo inicial descrito

en "RichFaces, trabajando con tablas (1)" para que no tengan que cargarse todos los objetos generados como resultado de la consulta en memoria.

Adems, vamos a hacer que el MBean utilizado para esta pgina NO tenga que encontrarse en el alcance de sesin:

...

public class MBean2 {

private DataModel facturas;

...

public DataModel getFacturas() {

return facturas;

}

public void setFacturas(DataModel facturas) {

this.facturas = facturas;

}

}

Pasamos a inyectar el modelo mediante el fichero de configuracin de JavaServer Faces:

...

paginacion2

es.ematiz.paginacion.MBean2

request

facturas

#{modeloFacturas}

...

Nota: el MBean asociado al modelo de datos llamado modeloFacturas ser definido posteriormente.

Es importante NO olvidar que vamos a tener que implementar una clase que herede de SerializableDataModel. Para entender de forma adecuada cmo hacerlo, se describen a continuacin las clases que se van a manejar:

La clase DataModel: clase perteneciente a la especificacin JavaServer Faces que permite definir modelos de datos avanzados.

La clase ExtendedDataModel: es una clase abstracta que define modelos de datos avanzados.

La clase SerializableDataModel: el modelo de datos ser una clase que hereda de sta.

La clase DataModel

Esta clase es una abstraccin de datos que puede utilizarse como fuente de datos para distintos componentes JSF que

soportan procesado de filas de sus componentes hijos.

La coleccin de datos subyacente de una instancia de DataModel se modela como una coleccin de objetos fila a la que se puede acceder mediante un ndice.

Mtodos:

getRowCount(): nmero de filas de objetos representados por la instancia DataModel.

getRowData(): devuelve el objeto representado por la fila seleccionada por el ndice de filas.

getRowIndex(): devuelve el ndice de filas.

...

Se recomienda analizar de forma detallada la clase mediante documentacin oficial.

La clase ExtendedDataModel

Es una extensin abstracta de DataModel definida por RichFaces para manejar estructuras de datos complejas.

- La clave o identificador para cada uno de los objetos no tiene que ser un ndice entero. Puede ser cualquier tipo de objeto. Para modelar esta idea se deben implementar los mtodos siguientes adaptndolos a nuestras necesidades:

public abstract void setRowKey(java.lang.Object key)

public abstract java.lang.Object getRowKey()

- El mtodo walk() ser el responsable de generar los objetos que va a manejar el componente JSF en la renderizacin.

public abstract void walk(

FacesContext context,

DataVisitor visitor,

Range range,

Object argument)

throws java.io.IOException

Este mtodo itera sobre el modelo mediante el patrn visitor para un rango dado.

Cada vez que el ciclo de vida JSF necesita recuperar el modelo de datos ejecuta este mtodo, es decir, en una situacin normal se ejecuta tres veces: fase de aplicacin de la peticin, fase de validacin y fase de actualizacin del modelo.

- El mtodo getSerializableModel(): un componente de iteracin puede soportar operaciones de guardado de datos en las

fases de decodificacin/validacin y actualizacin para evitar llamadas innecesarias al modelo original. Por ejemplo, para

evitar peticiones a la base de datos hasta que todos los datos estn validados.

Este mtodo se ejecuta una vez en el ciclo de vida estndar JSF, en la fase de renderizacin.

La clase SerializableDataModel

Hereda de ExtendedDataModel aadiendo un nuevo mtodo update() que slo se ejecuta cuando se lanza una accin dentro del componente JSF asociado en la fase de actualizacin del modelo:

Diseo del modelo de datos

Una vez descritas las tres clases importantes que nos permitirn crear el modelo de datos, pasamos a construirlo para nuestro ejemplo de Facturas.

Como ya se ha comentado el modelo de datos hereda de la clase SerializableDataModel:

...

public class FacturaDataModel extends SerializableDataModel{

// Atributos del modelo de datos

private static final long serialVersionUID = 1L;

// Clave o identificador de cada factura.

private Integer currentPk;

// Mapa que almacena id/Factura para los objetos que estn manejando

// la tabla en este momento.

private Map wrappedData =

new HashMap();

// Lista de los identificadores que est manejando la tabla

// en cada caso.

private List wrappedKeys = null;

private FacturaDataProvider dataProvider;

private boolean detached = false;

...

- El atributo currentPk representa a la clave primaria del objeto asociado a la tabla que se est manejando.

Para el caso de Factura, la clave es de tipo Integer, es por eso que currentPK es de tipo Integer. Si la clave primaria del

objeto manejado por la tabla fuera de otro tipo, deberamos cambiar tambin el tipo asociado a este atributo. Por ejemplo, si fuera una cadena de caracteres sera:

private String currentPk;

- El atributo wrappedData es un mapa que debe almacenar pares de datos: identificador nico del objeto y los objetos que

maneja la tabla en este momento. - El atributo wrappedKeys almacena los identificadores nicos de cada uno de los objetos que maneja la tabla.

private Map wrappedData =

new HashMap();

private List wrappedKeys = null;

- El atributo detached es un booleano que vamos a utilizar para indicar cundo hay que recuperar el modelo de datos de

la base de datos y cuando NO se debe hacer. Este atributo nos permite diferenciar entre peticiones que renderizan la tabla

paginada y peticiones POSTBACK. MUY IMPORTANTE a la hora de optimizar el acceso a la base de datos.

- El atributo dataProvider es el objeto Java que realmente se responsabiliza del acceso a base de datos. Posteriormente, se describe el proceso para crear esta clase.

El diseo del modelo de datos implica la implementacin los mtodos anteriormente comentados:

Mtodo walk.

Mtodo getSerializableModel.

Mtodo update.

Mtodo getRowCount.

Mtodo getRowData.

El mtodo walk()

public void walk(FacesContext context, DataVisitor visitor,

Range range,

Object argument) throws IOException {

// Paso 1: Se recupera el rango de datos con el que trabaja la tabla

// paginada.

int firstRow = ((SequenceRange)range).getFirstRow();

int numberOfRows = ((SequenceRange)range).getRows();

// Se comprueba si el modelo esta serializado

if (detached) {

// Paso 2.1: Si el modelo est serializado NO se accede de nuevo

// a la base de datos.

for (Integer key:wrappedKeys) {

setRowKey(key);

visitor.process(context, key, argument);

}

} else {

// Paso 2.2: Si el modelo no esta serializado hay que volver a

// recuperarlo.

wrappedKeys = new ArrayList();

// Para recuperar el modelo se actua sobre el proveedor

// de datos, dataProvider.

for (Factura f:dataProvider.getItemsByRange(firstRow,

numberOfRows)) {

wrappedKeys.add(f.getCodfactura());

wrappedData.put(f.getCodfactura(), f);

visitor.process(context, f.getCodfactura(),

argument);

}

}

}

El mtodo getSerializableModel()

public SerializableDataModel getSerializableModel(Range range) {

if (wrappedKeys!=null) {

detached = true;

return this;

} else {

return null;

}

}

El mtodo update()

Este mtodo se ejecuta, dentro del ciclo de vida JSF en la fase de actualizacin del modelo, como resultado de una accin

dentro de la tabla que, evidentemente, tiene que enviar la tabla como parte de la informacin a procesar en el servidor. Inicialmente este mtodo puede estar vaco:

public void update() {

}

El mtodo getRowData()

Devuelve el objeto asociado al identificador actual.

public Object getRowData() {

if (currentPk==null) {

return null;

} else {

Factura ret = wrappedData.get(currentPk);

if (ret==null) {

// Se utiliza el proveedor de datos para recuperar el objeto

// asociado a una determinada clave o identificador.

ret = getDataProvider().getItemByKey(currentPk);

wrappedData.put(currentPk, ret);

return ret;

} else {

return ret;

}

}

}

El mtodo getRowCount()

Devuelve el nmero de filas total de la informacin con la que se trabaja.

private Integer rowCount;

@Override

public int getRowCount() {

if (rowCount==null) {

rowCount = new Integer(getDataProvider().getRowCount());

return rowCount.intValue();

} else {

return rowCount.intValue();

}

}

El modelo de datos se define en el alcance request.

modeloFacturas

es.ematiz.paginacion.modelo.FacturaDataModel

request

dataProvider

#{proveedorFacturas}

El proveedor de datos va a ser definido como MBean y, como se puede ver en el cdigo, ser inyectado en el modelo de

datos como una propiedad manejada. Se describe a continuacin el proceso de creacin de dicho proveedor.

El proveedor de datos

Es el objeto responsable de la interaccin con el sistema de almacenamiento sobre el que trabajamos para recuperar la

informacin. Esta clase debe implementar la interface DataProvider que se encuentra en el paquete

org.richfaces.model. Esta especificacin define los siguientes mtodos:

getItemByKey: devuelve un objeto a partir de su clave.

getItemsByRange: devuelve una lista de objetos en funcin de un rango de valores definido como parmetro.

getKey: devuelve la clave asociada a un objeto pasado como parmetro.

getRowCount: nmero de filas total.

Siguiendo nuestro ejemplo, el proveedor de datos para Facturas sera algo tal que as:

...

public class FacturaDataProvider

implements DataProvider{

// Atributos de la clase

private static final long serialVersionUID = 1L;

private Integer size = null;

private List rango;

private Map mapa =

new HashMap();

...

}

- El atributo size define el nmero de elementos que se manejan.

- El atributo rango define el conjunto de objetos que realmente se van a cargar en memoria. - El atributo mapa almacena pares Identificador de objeto, objeto.

El mtodo getItemByKey()

Como su nombre indica, este mtodo debe devolver el objeto asociado a una determinada clave o identificador.

@Override

public Factura getItemByKey(Object key) {

// Uno de los atributos de la clase es una mapa que almacena pares

// claves/Objetos, por lo tanto, teniendo la clave recuperar el

objeto

// es algo evidente.

return mapa.get(key);

}

El mtodo getKey()

Este mtodo recupera la clave asociada al objeto pasado como parmetro.

@Override

public Object getKey(Factura f) {

// Para el caso de la clase Factura, su clave es codigo.

return f.getCodigo();

}

El mtodo getItemsByRange()

Es el mtodo ms importante, siendo responsable de la recuperacin de SLO los objetos que va a mostrar la tabla en

cada momento, es decir SLO recupera el rango definido mediante los parmetros firstRow y endRow.

public List getItemsByRange(int firstRow, int endRow) {

FacturaBD servicio = new FacturaBD();

rango = servicio.findFacturas(firstRow, endRow);

Iterator it = rango.iterator();

while (it.hasNext()) {

Factura factura = (Factura) it.next();

mapa.put(factura.getCodfactura(), factura);

}

return rango;

}

El mtodo getRowCount()

Este mtodo devuelve como valor de retorno el nmero total de datos con los que trabaja la tabla. Este valor determina el

tamao del scroller asociado a la tabla.

@Override

public int getRowCount() {

if(size==null){

FacturaBD servicio = new FacturaBD();

size = servicio.getNumFacturas();

}

return size.intValue();

}

Declaracin del proveedor en faces-config.xml

El proveedor de datos debe ser un objeto definido en el alcance sesin, vamos a aprovechar el fichero de configuracin de

JavaServer Faces para definirlo y posteriormente inyectarlo en el modelo de datos:

proveedorFacturas

es.ematiz.paginacion.modelo.FacturaDataProvider

session

Como ya se ha comentado anteriormente, el proveedor debe ser inyectado en el modelo de datos. Se muestra de nuevo la estructura que debemos incluir en el fichero de configuracin de JavaServer Faces.

modeloFacturas

es.ematiz.paginacion.modelo.FacturaDataModel

request

dataProvider

#{proveedorFacturas}

Incorporacin en la vista

El modelo de datos definido y su proveedor asociado han sido definidos aprovechando la inyeccin de dependencias de

JSF. Para poder utilizarlos en la vista slo debemos utilizar lenguaje de expresin:

...

A continuacin se muestra el resultado:

No se cargan en memoria todos los objetos, SLO los que se estn visualizando en la tabla.

Anlisis del ciclo de vida

La primera vez que se quiere visualizar la pgina, el ciclo de vida (como ya hemos comentado anteriormente es ms

corto):

Fase de restauracin de la vista.

Fase de renderizacin: en esta fase se ejecutan los mtodos del modelo de datos anteriormente descritos. En el caso del mtodo walk(), como la variable detached est a falso, obligatoriamente accede a base de datos y recupera SLO

los objetos que va a mostrar la tabla. El nmero de objetos cargados en memoria es mucho menor que en el primero

caso. Posteriormente, se ejecuta el mtodo getSerializableModel() que devuelve el modelo serializado poniendo la

variable detached a verdadero (esto provoca que cuando se hagan peticiones sobre la pgina -Postbacks- no se recupere el modelo de la base de datos, ya que se encuentra serializado).

Finalmente, se obtiene el resultado de la renderizacin:

Para este caso, las nicas acciones que vamos a poder generar sobre la tabla se realizan mediante el scroller.

ste va a lanzar una nica peticin a base de datos en la fase de renderizacin. En las dems fases no se hace nada

relacionado con el acceso a base de datos, por lo tanto, todo correcto.

RichFaces, trabajando con tablas (3): ordenacin y filtrado manuales

Introduccin

El uso de los atributos sortBy y filterBy del componente rich:column NO ser vlido cuando se trabaja con modelos de

datos complejos como el que se present en el artculo "RichFaces, trabajando con tablas (2)". Se deben implementar mecanismos de ordenacin y filtrado manuales que sean capaces de manejar este modelo paginado.

Se van a definir commandLinks dentro de las columnas de la tabla que van a lanzar peticiones Ajax para modificar el orden en el que se muestran los datos dentro del dataTable.

Se van a crear inputText para definir mecanismos de filtrado.

Ordenacin manual

Modificaciones en la vista

Para aplicar ordenacin sobre una estructura de datos compleja se debe modificar la renderizacin. Se incorpora una

nueva accin dentro de la faceta de cabecera que pasa como parmetro, en la peticin que genera, el campo a partir del cul se va a ordenar.

Por ejemplo, si se hace click sobre la columna Cdigo de factura se enviar un parmetro llamado sortField cuyo valor ser codfactura y cuando se genere la respuesta se re-renderizar la tabla paginada:

En este caso se deben utilizar atributos para optimizar el envo de informacin? ajaxSingle = true? No, la peticin desencadenada por esta accin debe enviar la informacin de la tabla para poder procesarla mediante el ciclo de vida

estndar.

Algn tipo de renderizacin adicional? Queremos que, una vez que el orden de los datos sea modificado, slo sea re-

renderizada la tabla. Los dems contenidos de la pgina deben quedar intactos.

Por esta razn, se utiliza en atributo reRender asociado a la tabla.

var="f" rows="5" reRender="scroll01" width="100%">

El mtodo update()

El modelo de datos propuesto en el artculo "RichFaces, trabajando con tablas (2)" incorpora un mtodo llamado update()

como responsable de todos los procesos de actualizacin del modelo. Este mtodo se ejecuta, dentro del ciclo de vida JSF

en la fase de actualizacin del modelo, como resultado de una accin dentro de la tabla que, evidentemente, tiene que

enviar la tabla como parte de la informacin a procesar en el servidor. El caso que estamos analizando cumple todas esas condiciones. Por esta razn, este mtodo nos va a permitir implementar el concepto de ordenacin.

...

public void update() {

// Codigo para cambiar el criterio de ordenacin.

}

...

Se muestra a continuacin cdigo de ejemplo:

@Override

public void update() { // Paso 1: Se comprueba si se aplica criterio

de ordenacin.

if(getCriterioOrdenacion()!=null){

// Paso 2: Se recupera al criterio de ordenacin a aplicar.

final String nuevoCriterio = getCriterioOrdenacion().toString();

// Paso 3: Se comprueba si el criterio de ordenacin es igual al

que est activo.

if(nuevoCriterio.equals(dataProvider.getOrdenacion())){

// Paso 4: Si el criterio de ordenacin es el mismo, debemos

cambiar

// el orden.

dataProvider.setDescendente(!dataProvider.isDescendente());

}

dataProvider.setOrdenacion(nuevoCriterio);

}

// El atributo detached indica si el modelo de datos est serializado

o si hay

// que volver a la base de datos a recuperar la informacin de nuevo.

// En el caso de un cambio de ordenacin, debemos lanzar una nueva

consulta.

detached = false;

}

Como se ha podido ver en el cdigo, se crea y utiliza un mtodo auxiliar llamado getCriterioOrdenacion para manejar el

criterio de ordenacin:

protected Object getCriterioOrdenacion(){

// Paso 1: Se recupera el contexto JSF

final FacesContext contexto = FacesContext.getCurrentInstance();

// Paso 2: Se obtiene el parametro pasado en la peticin.

final Object o =

contexto.getExternalContext().getRequestParameterMap().get("sortField");

return o;

}

El mtodo getItemsByRange del proveedor

Lgicamente, este mtodo debe ser modificado para manejar el concepto de ordenacin. Por ejemplo

servicioContabilidad.findAllPaginandoOrdenando(inicio, tam, asc,

propiedad);

Anlisis del ciclo de vida

La primera vez que se quiere visualizar la pgina, el ciclo de vida (como ya hemos comentado anteriormente es ms

corto):

Fase de restauracin de la vista.

Fase de renderizacin:

En esta fase se ejecutan los mtodos del modelo de datos anteriormente descritos. En el caso del mtodo walk(), como la variable detached est a falso, obligatoriamente accede a base de datos y recupera SLO los objetos que

va a mostrar la tabla. El nmero de objetos cargados en memoria es mucho menor que en el primero caso.

Posteriormente, se ejecuta el mtodo getSerializableModel() que devuelve el modelo serializado poniendo la variable detached a verdadero (esto provoca que cuando se hagan peticiones sobre la pgina -Postbacks- no se recupere el modelo de la base de datos, ya que se encuentra serializado).

Una vez que la pgina se renderiza, se muestra:

Al hacer click sobre el enlace Cdigo de factura se genera una peticin al servidor. En ese caso se desencadena un ciclo de vida completo:

La peticin es de tipo POSTBACK, es decir, el modelo est serializado y la variable detached est a true, por lo tanto, aunque se ejecute el mtodo walk() del modelo NO se lanzan consultas a la base de datos.

Cuando se llega a la fase de actualizacin se ejecuta el mtodo update(). ste cambia el criterio de ordenacin y pone la variable detached a falso.

En la fase de renderizacin, como detached est a falso, cuando se ejecuta el mtodo walk() S se accede a la base de datos aplicando el criterio de ordenacin seleccionado. Como en la vista el atributo reRender est asociado a la tabla, sta vuelve a renderizarse con los nuevos valores.

Filtrado manual

Conceptualmente, este proceso es muy parecido al de ordenacin. Se debe modificar la vista para incorporar un campo

que acte como filtro y, posteriormente, se debe modificar el modelo de datos que proporciona registros a la tabla para que cuando se active el filtro acte en consecuencia.

Modificaciones en la vista

Se incorpora un campo de texto que genera peticiones AJAX para activar el proceso de filtrado:

...

...

Modificaciones en el mtodo getItemsByRange()

Se debe modificar este mtodo para que sea capaz de manejar filtros:

...

rango = servicioContabilidad.

findAllPaginandoOrdenandoFiltrado(

firstRow,

endRow,

!descendente,

ordenacion,

filtroConcepto);

...

El resultado de estas modificaciones generan la siguiente vista:

Si se escribe en el filtro se genera un filtrado: