Las librerías xLibrary, para el trabajo con DHTML compatible con todos los navegadores, contienen un nutrido grupo de funciones que además están separadas en varios archivos de código javascript. Estas funciones se deben importar desde el código fuente de las páginas que hacen uso de ellas.

Lo que a veces no es tan sencillo es conocer qué grupo de funciones se deben importar en cada momento, ya que hay muchas librerías que además tienen dependencias entre si.

En versiones anteriores de xLibrary la mayoría de las funciones más habituales se encontraban en un fichero llamado x_core.js y en muchos casos bastaba con incluirlo. Un problema de ese fichero es que casi siempre contenía mucho más código del que realmente utilizábamos. Para que ocupe menos el fichero de las librerías y sea transferido más rápidamente por la Red, en ocasiones lo había editado a mano, para quitarle aquellas funciones que no se utilizaban.

Nota: Los primeros ejemplos del Taller de Cross-Browser DHTML incluyen el mencionado archivo x_core.js porque la herramienta X Library Compiler no estaba creada todavía.

A partir de la versión 4.0, el orden del código ha cambiado un poco y ahora no basta con incluir x_core.js. Ahora hay que utilizar una herramienta lamada X Library Compiler, que está preparada para crear el fichero de librerías optimizado para el uso en nuestra aplicación web. X Library Compiler (XC) hace un análisis del código de nuestra página y genera un archivo con el código que necesitamos incluir, es decir, personaliza las librerías, creando un archivo que incluye sólo aquello que necesitamos.

Con esto se simplifican dos aspectos. Por un lado, no tenemos que preocuparnos por qué librerías debemos incluir y por otro, el código que incluimos siempre es seguro que contiene las partes estrictamente necesarias de las xLibrary.

Utilizar XC para crear el archivo .js a incluir

El problema de utilizar XC es que es un poco complicado en un principio. XC está programado en VC++ para Windows y se tiene que ejecutar por línea de comandos. Además, tenemos que crear un archivo de configuración para que haga exactamente lo que necesitamos. Trataremos de explicar los pasos necesarios para que cualquier persona pueda utilizar XC.

Nota: este procedimiento está descrito siguiendo la metodología de la versión 4.0 de xLibrary. Puede que cambie en versiones posteriores.

1) Accedemos desde línea de comandos al directorio donde está XC.
Es el directorio donde se han descomprimido las xLibrary. Puede ser algo como C:\x\xc.

2) Creamos un archivo de configuración del proyecto
Es necesario crear un archivo de texto con las configuraciones para que XC opere tal como nosotros deseamos. El fichero tiene que tener extensión .xcp, por ejemplo, miproyecto.xcp.

El archivo de configuración tiene una sintaxis especial, que veremos sobre el propio fichero de ejemplo:

; XC Project: miproyecto
options
libpath ..\lib\
appfiles
..\..\misejemplos\animacion_texto_3.html

Cualquier línea que empiece por ";" es un comentario. Luego la primera línea es un comentario.
En la segunda línea se indican las opciones. No he indicado ninguna opción, por lo que estamos señalando que opere con las opciones por defecto.
La tercera línea es la ruta relativa hacia el directorio que contiene las librerías.
La cuarta línea que pone "appfiles" indica que se va a proceder a escribir la ruta donde están los archivos que hacen uso de las funciones de xLybrary.
En la quinta y sucesivas líneas se indica la ruta, también relativa, para llegar a los archivos de nuestra aplicación que hacen uso de xLibrary. Se pueden indicar uno o más ficheros.

3) Ejecutar XC
Ahora tenemos que poner en marcha la herramienta xLibrary Compiler para generar un archivo .js que tendremos que incluir en las páginas web que utilicen las librerias cross browser. Para ello, desde el directorio donde se han descomprimido las xLibrary y en el subdirectorio donde está el archivo xc.exe, algo como C:\x\xc, se ejecuta el mencionado archivo xc.exe enviando como parámetro el nombre del archivo de proyecto que habíamos creado antes.

C:\x\xc>xc miproyecto

4) Obtener el archivo generado
Si la ejecución de XC ha sido correcta se genera el archivo que nuestras aplicaciones deberían incluir. Si ha fallado suele ser porque hemos escrito mal una ruta o algo así. No obstante, los mensajes de error son bastante descriptivos, lo que facilita las cosas si algo va mal.
El archivo generado tendrá el nombre miproyecto.js. Simplemente podemos copiar ese fichero, situarlo en nuestra aplicación e incluirlo desde la página web.

<script src="miproyecto.js" type="text/javascript"></script>

Este código serviría para incluir el archivo miproyecto.js. En este caso se supone que el archivo a incluir está en el mismo directorio que la página que lo incluye.

Opciones de XC

Se incluyen algunas opciones de configuración de XC, que pasan desde la creación de logs hasta marcar si se desean o no seguir las dependencias entre funciones de xLibrary.

• cmp - Si es verdadero, indica que se debe comprimir el archivo generado. La compresión elimina los saltos de línea, sangrados y algunos comentarios. (Verdadero por defecto)
  
• lws - Si es verdadero indica que se deben conservar los espacios en blanco. (Por defecto es falso)
  
• nln - Si es verdadero indica que se deben conservar los saltos de línea en las líneas que no están vacías. (Por defecto falso)
  
• bln - En caso verdadero se conservan las líenas en blanco. (Defecto Falso)
  
• log - Si es verdadero, se crean archivos de log. (Por defecto Falso)
  
• lib - En caso verdadero se genera el archivo de librería. (Verdadero por defecto)
  
• glb - Si es verdadero, incluye globals.js. (Defecto es verdadero)
  
• dbg - Si es verdadero se hace un debug en el fichero de log. (Falso por defecto)
  
• dep - En caso verdadero se incluyen dependencias en la librería. Cuando está en falso es útil para crear una librería a partir de una lista de símbolos de X Library. El autor del programa usa esta opción para crear un archivo librería como x_core.js (que incluye la mayoría de las funciones) o x_event.js que incluye funciones para gestión de eventos. La lista de símbolos a incluir se escribe en el archivo .xcp, en la sección appfiles, comentada con un ";". Se puede ver el archivo x/x_core.xcp para ver un ejemplo.

Otro ejemplo de archivo de configuración que incorpora algunas opciones es el siguiente:

options +log +dbg -cmp
libpath ..\lib\
appfiles
..\..\misejemplos\otroejemplo.php
..\..\misejemplos\xyz.php

Las opciones indicadas en este fichero son que se cree un archivo de log (el archivo de log se creará con el nombre del proyecto y extensión .log), que se incluyan informaciones de debug en el log y que no se comprima el código de la librería resultante. En este caso se han indicado dos ficheros de aplicación que contienen cógigo javascript. Los archivos donde están los scripts javascript pueden tener cualquier extensión, en este caso .php.

Conclusión

Sin duda XC es una herramienta útil para mantener el juego de funciones estrictamente necesario para nuestros scripts. Aunque el propio autor comenta varias líneas de desarrollo que está barajando para mejorar esta herramienta.

El único problema que he encontrado es que en uno de nuestros scripts habíamos utilizado una función de las xLibrary dentro de un setTimeout() de Javascript y XC no había detectado esta función y no la había incluido dentro de la librería generada. Por ejemplo en un código como este:

setTimeout("xShow('ampliacion')",50)

Con un código como este, XC pasaba por alto que estábamos utilizando la función show() y por tanto no la incluía.

La herramienta acaba de ver la luz en el momento de escribir este artículo, por lo que es posible que cuando alguien lea estas líneas este error (y otros que pueda haber) se haya solventado e incluso que la aplicación haya mejorado o modificado el modo de trabajo.