En la nueva versión 1.7 ésto no será necesario para la mayoría de las situaciones: Si puedes acceder a los datos de tu xml siguiendo rutas como:

/gallery/photos/photo
/gallery/photos/*
gallery/photos/photo
/gallery//photo
//photo
//photo/@path
//photo/@*

En todos estos casos, ya no será necesario enlazar al archivo xpath.js, con la consiguiente ventaja en tiempos de descarga.

Si tus rutas son más complicadas o utilizan otro tipo de estructura diferente a las indicadas, deberás seguir incluyéndolo.

La actualización consiste en un sencillo mxp que se instala a través del Extension Manager.

La URL es:
http://www.adobe.com/cfusion/entitlement/index.cfm?e=labs_spry

El motivo para ello es asegurarnos de que aunque haya conexión, el XML remoto está disponible (el sitio podría estar caído). Al mismo tiempo tiempo queríamos evitar una doble conexión (una para comprobar el estado y otra para leerlo). Para ello partimos de un xml local. El código realiza estos pasos:

1. Crea un dataset de Spry vacio
2. Se intenta conectar con el xml remoto: Si lo encuentra, actualiza el xml local. En caso contrario, el xml local permanece sin alterar
3. Hacemos que Spry cargue el xml local (que ya estará actualizado si el remoto estaba disponible)

El primer paso es cargar los archivo js necesarios de AIR y Spry:

<script type="text/javascript" src="js/AIRAliases.js"></script>
<script src="SpryAssets/xpath.js" type="text/javascript"></script>
<script src="SpryAssets/SpryData.js" type="text/javascript"></script>

A continuación comienza el bloque de script: Las primeras seis lineas crean el dataset, la conexión y definen 2 listeners para gestionar la lectura o el error en su caso; finalmente, leemos el contenido de la url:

//Creamos un dataset vacio, que cargaremos más adelante llamando a loadDataset()
var ds1 = new Spry.Data.XMLDataSet(null, "events/event",{useCache:false});
//llamamos al archivo externo
//añadimos 2 listeners para gestionar la lectura del archivo o el error de lectura
var urlRemota = new air.URLRequest("http://www.dwug.es/spry/3/events.xml");
var loader = new air.URLLoader();
loader.addEventListener(air.Event.COMPLETE, lecturaCompleta);
loader.addEventListener(air.IOErrorEvent.IO_ERROR, errorIO);
loader.load(urlRemota);

La función loadDataSet se encarga de cargar el archivo xml local:

function loadDataset(){
ds1.setURL("data/eventos.xml");
ds1.loadData();
}

La función errorIO se encarga de cambiar el texto de un div del documento a ‘offline’ y carga el dataset local (que no se ha modificado, ya que ha habido un error):

function errorIO(event){
document.getElementById('estado').innerHTML="Offline";
loadDataset();
}

La función lecturaCompleta (invocada si se ha relizado la conexión y se ha leido el xml remoto) se encarga de sobreescribir el xml local y cargar el dataset (que ahora ya estará actualizado):

function lecturaCompleta(event){
document.getElementById('estado').innerHTML="Online";
//obtenemos el contenido del xml remoto
var dataXML = event.target.data;
//buscamos el archivo local: primero su carpeta y luego el archivo
var carpetaDestino=air.File.applicationResourceDirectory.resolve("data");
var archivoDestino = carpetaDestino.resolve("eventos.xml");
//Abrimos el fileStream para poder acceder al archivo
var destinoStream = new air.FileStream();
//listener para avisar de que se ha escrito
destinoStream.addEventListener(air.Event.CLOSE, escrituraCompleta);
//Abrimos de forma asíncrona, para que lance el evento al terminar
destinoStream.openAsync(archivoDestino, air.FileMode.WRITE);
//sobreescribimos el archivo local
destinoStream.writeUTFBytes(dataXML);
//cerramos el fileStream
destinoStream.close();
}

Finalmente, la función escrituraCompleta se invoca cuando se ha terminado de sobreescribir el xml local con los datos remotos. se limita a cargar el dataset:

function escrituraCompleta(event){
loadDataset();
}

El código completo del documento puede verse en la siguiente URL:
http://www.dwug.es/spry/spry_air_online_offline.txt

Vamos a aplicarlo al efecto resaltado de Spry que viene incluido en DW CS3. En su aspecto por defecto, en DW encontraremos este codigo. Incluye el enlace archivo SpryEffects.js que carga los efectos y una función (MM_effectHighlight) que acepta como parámetros:

• Elemento para el efecto
• Duración
• Color de inicio
• Color durante la transición
• Color final
• Si el efecto se realizará al revés en su próxima llamada por el usuario (al volver a hacer click de nuevo, por ejemplo)

Este efecto se encuentra en el panel de Etiquetas -> pestaña Comportamientos -> Efectos -> Resaltado

El código que se creará es el siguiente:

<script src="/SpryAssets/SpryEffects.js" type="text/javascript"></script>
<script type="text/javascript">
function MM_effectHighlight(targetElement, duration, startColor, endColor, restoreColor, toggle){
    Spry.Effect.DoHighlight(targetElement, {duration: duration, from: startColor, to: endColor, restoreColor: restoreColor, toggle: toggle});
}
....
<div onclick="MM_effectHighlight(this, 1000, '#FFFFFF', '#0099FF', '#0099FF', false)">Click Me</div>

Y este es el efecto resultante:

Como se puede ver, el efecto no realiza una transición hasta su color de origen. Como mucho, podemos cambiar toggle a ‘true’ para que haga el efecto inverso cuando volvamos a pulsar.

Aquí es donde entran los atributos ’setup’ y ‘finish’. En nuestro script vamos a capturar el momento en el que el efecto termina para que cree inmediatamente después un efecto con los colores inversos. Para distinguirla de la original, le hemos cambiado el nombre de MM_efectHighlight a TCN_effectHighlight:



....

Es decir, le hemos añadido la opción finish al constructor y le asignamos como valor una nueva función que realizará el mismo efecto pero al revés (from: endColor, to: startColor, restoreColor: startColor).

El resultado en este caso es el que deseamos:

En caso de utilizar setup, la función que le asignemos será ejecutada antes de comenzar el efecto.

Como nota final, Spry ofrece la posibilidad de crear clusteres de efectos que pueden ejecutarse de forma simultánea o uno después de otro. Lo veremos en el futuro.

Un acordeón básico de un solo panel tiene esta estructura:

El ejemplo anterior funcionará sin problemas, pero: ¿Qué sucede si intentamos aplicarle una región repetida?

<div class="Accordion" id="Accordion1" spry:region="empleados">
  <div class="AccordionPanel" spry:repeat="empleados">
    <div class="AccordionPanelTab">{nombre}</div>
    <div class="AccordionPanelContent">{datos}</div>
  </div>
</div>
<script type="text/javascript">
<!--
var acc = new Spry.Widget.Accordion("Accordion1");
//-->
</script>

En este caso, El widget no funcionará. La explicación es sencilla: El widget se crea al mismo tiempo que la región repetida, por lo que aquél es incapaz de controlar todos los paneles que aún no han sido creados. Debemos por tanto encontrar la forma de saber cuándo Spry ha terminado de crear todos los paneles para convertirlos en un acordeón. Para ello tenemos los observers.

Existen elementos de Spry (como las regiones y los datasets) que lanzan notificaciones cuando cambian. Estas notificaciones, similares a los eventos, pueden ser ‘observadas’ por un observer (valga la redundancia), que entrará en funcionamiento cuando se produzca alguna notificación.

En nuestro caso, necesitamos comprobar los cambios en una región, la cual puede realizar las siguientes notificaciones:

• onLoadingData: La región está cargando los datos desde el dataset
• onPreUpdate: Los datos se han cargado y la región está a punto de reescribirse con el nuevo html
• onPostUpdate: La región ya se ha regenerado con el nuevo html y se ha insertado en el documento
• onError: Ha ocurrido algún error durante el proceso

Por lo tanto, cuando la región envie la notificación onPostUpdate podremos crear el acordeón sin problemas, ya que todo el html ha sido generado.

Aquí entran en juego los observers: Son objetos o funciones (se aceptan ambos y su funcionalidad es similar), que se encargan de vigilar las notificaciónes enviadas por parte de la región y qué hacer cuando eso sucede. Para nuestro ejemplo, utilizaremos un objeto.

Un objeto observer tiene esta estructura:

//creamos el objeto
var miObserver = new Object;
//le decimos  miObserver lo que tiene que hacer cuando recibe un onPostUpdate
//En nuestro caso, debe crear un acordeon
miObserver.onPostUpdate = function()
    {
    var acc1 = new Spry.Widget.Accordion("Accordion1");
    };
//Finalmente, indicamos que miObserver estará pendiente del elemento 'Accordion1'
	Spry.Data.Region.addObserver("Accordion1", miObserver);

A partir de ahora,cuando el elemento ‘Accordion1′ se regenere y envie la notificación onPostUpdate, el observer que hemos creado (miObserver) se encargará de crear el acordeon.

El codigo final es:

<head>
(...)
<script type="text/javascript">
<!--
//creamos el dataset
var empleados = new Spry.Data.XMLDataSet("empleados.xml", "empleados/empleado");
//creamos el observer
var miObserver = new Object;
miObserver.onPostUpdate = function()
    {
		   acc = new Spry.Widget.Accordion("Accordion1");
    };
	Spry.Data.Region.addObserver("Accordion1", miObserver);
//-->
</script>
(...)
</head>
<body>
<!--Creamos el bloque del futuro acordeon -->
<div class="Accordion" id="Accordion1" spry:region="empleados">
  <div class="AccordionPanel" spry:repeat="empleados">
    <div class="AccordionPanelTab">{nombre}</div>
    <div class="AccordionPanelContent">{datos}</div>
  </div>
</div>
</body>

• Un bloque contenedor
• Bloque de panel 1
• Un bloque de pestaña/titulo
• Un bloque de contenido
• Bloque de panel 2
  • Un bloque de pestaña/titulo
  • Un bloque de contenido
• …Bloque de panel n
  • Un bloque de pestaña/titulo
  • Un bloque de contenido

Estos bloques no necesitan ser obligatoriamente etiquetas div, sino que Spry es capaz de realizarlos con otros elementos html, como una lista.

Una enlazado al archivo creada la estructura de bloques, sólo nos queda instanciar el objeto:

La asignación a la variable nos permitirá realizar otrs acciones posibles, como abrir un determinado panel, crearlos al vuelo… El valor del parámetro es la id que asignemos al bloque que actua como contenedor.

En el ejemplo 1 podemos ver la estructura básica de un acordeón que utiliza una lista para presentar los datos.

Para el primero de los casos se mantiene la función filterData(), que ya existía en las versiones anteriores de Spry. Ahora, se añade la función filter(), que permite realizar filtrados en los que los datos no utilizados no desaparecen, sino que se mantienen (de ahí su definición de filtrado no destructivo).

Este tutorial es un ejemplo del uso de esta función: Se trata de crear un campo de texto en el queiremos escribiendo texto y que de forma dinámica, irá realizando un filtrado de los datos, los cuales se actualizarán en el documento sin necesidad de recargar. Un ejemplo en la vida real puede ser el quehace Google para ir mostrando posibilidades de búsqueda que coincidan con el texto escrito. Nuestr caso práctico mostrará un listado de productos de Adobe. A medida que escribamos en el campo de texto, se irán eliminando aquellos cuyo nombre no coincida con lo escrito.

El ejemplo en funcionamiento está disponible haciendo click aquí.
Pusa aquí para ver el archivo products.xml.
Puedes descargarte el ejemplo completo y listo para funcionar desde aquí.

Nuestro primer caso, como en toda aplicación que use Spry, es definir el namespace y llamar a los 2 archivos js (xpath.js y SpryData.js) necesarios. Debemos recordar que a partir de esta versión 1.1, la sintaxis difiere de la utilizada en versiones anterios (para conseguir la validación como xhtml):

Buscar Producto :




{name}

Hasta ahora, simplemente hemos creado una región repetida (con la etiqueta li) que nos mostrará todos los productos obtenidos del fichero xml. Nuestro siguiente paso será añadir una función que realice el filtrado.