Bestiario XUL

Este documento sobre XUL presenta algunos de los conceptos clave y términos del entorno de desarollo XUL. El propósito de este artículo no es explicar estos elementos en profundidad sino decir lo que son en términos sencillos. Se han seleccionado los elementos para este grupo porque parecen que están inmersos en el misterio, que son poco usados como conceptos o términos, o que son infravalorados de acuerdo a su papel en XUL y al desarrollo multiplataforma. En contraposición al Mozilla Jargon File , este artículo explica los elementos de especial interés para el desarrollo web o de contenidos y pretende establecer un contexto para comprender las nuevas tecnologías de Mozilla y en particular el lenguaje de interfaces de usuario basado en XML de Mozilla: XUL.

Chrome

Algunas de las más potentes y con frecuencia incomprendidas características de XUL y del navegador Mozilla tienen que ver con chrome. El término chrome es usado en diferentes contextos para referirse a cosas distintas. En general, chrome se refiere a una interfaz XUL y a todos sus ficheros de apoyo. chrome quiere decir que el contenido y estructura XUL + la apariencia que le da CSS + cualesquiera ficheros de configuración regional y específicos de la plataforma son parte de dicha interfaz XUL. En comparación, la apariencia es sólo el CSS y los gráficos referenciados para el fichero XUL, las cadenas de texto de la configuración regional están almacenadas en un DTD y el contenido es sólo el XUL.

La URL chrome

El concepto de chrome como algo integrado y dinámico separado de alguna forma del núcleo de la aplicación se realiza a través de la url chrome apuntando a partes de XUL a sus ficheros relacionados. La url chrome se parece a las direcciones http, como se muestra en la siguiente instrucción de proceso de apariencia global:

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

Esto especifica un chrome para que pueda ser cargado por el motor de renderizado Gecko. En el ejemplo anterior, el chrome es simplemente un fichero de apariencia cargado en el fichero XUL, aunque el chrome puede además cargar otros chromes, como cuando un menuitem de una ventana muestra un nuevo chrome:

<menuitem 
  value="Mozilla Help" 
  oncommand="window.openDialog('chrome://help/content/help.xul',
                               '_blank',
                               'chrome,all,dialog=no')" />

En el ejemplo anterior, la url chrome se usa para apuntar a un chrome dentro de la jerarquía de paquetes de la aplicación Mozilla. Existe un chrome Help definido en mozilla/bin/chrome/help que es invocado desde el menú de Ayuda. Nótese que cuando no se especifica el nombre de fichero en la ruta del directorio del chrome se supone que dicho nombre de fichero coincide con el del paquete. En otras palabras, una url chrome como el apuntador global de antes pediría un fichero llamado global.css y el apuntador de ayuda anterior podría ser reescrito como 'chrome://help/content' dado que el nombre del paquete es "help".

Ver otros chromes que no son de Mozilla

Existe un modificador especial que puede ser usado al iniciar Mozilla con algún otro chrome diferente al predeterminado. Cuando Mozilla es ejecutado desde la línea de comandos con el modificador -chrome, se puede especificar el chrome que se quiera, como el del anterior ejemplo.

mozilla -chrome chrome://help/content/help.xul

Esto mostrará el paquete de ayuda mencionado anteriormente como un chrome independiente . Esta opción especial te permite crear y acceder a chromes independientes del navegador Mozilla y es un punto de inicio para explicar las posibilidades de XUL como plataforma más alla del simple rediseño del navegador.

Paquetes

Un paquete es de algún modo parecido a un chrome pero específico para la arquitectura de Mozilla. Un paquete es un trozo de código de interfaz que se ubica en un lugar en particular dentro de la jerarquía de paquetes de Mozilla. Como un chrome, dicho trozo generalmente alberga contenido XUL, información de apariencia CSS y gráficos, cadenas de configuración regional y quizá algo de código específico para la plataforma. El navegador es un paquete definido en mozilla/bin/chrome/navigator, la parte de correo y noticias es un paquete situado en mozilla/bin/chrome/mailnews/, etc... El directorio de cada paquete tiene tres subdirectorios: content, skin y locale; en el que se ubican el XUL, el CSS y la información de configuración regional, respectivamente:

navigator/
  content/
    default/
      navigator.xul
      ...
  skin/
    default/
      navigator.css
      nav-icon.gif
      ...
  locale/
    US-en/
      navigator.dtd

El directorio predeterminado (default) subyacente de cada uno de esos subdirectorios del paquete principal se asume en la url chrome (p.e.: chrome://help/content/help.xul no incluye un directorio predeterminado como parte de la url, pese a que dicho directorio exista en la estructura real). Cuando se crean diferentes chromes para un paquete, se puede crear un directorio subyacente al directorio content cuyo contenido será cargado en lugar del predeterminado. Por ejemplo, si se quiere crear una nueva apariencia con la que dotar al paquete navigator se puede crear un subdirectorio bajo navigator/skin/ cuyo contenido sea cargado en lugar del predeterminado. Así, la estructura quedaría:

navigator/
  content/
    default/
      navigator.xul
      ...
  skin/
    default/
      navigator.css
      nav-icon.gif
      ...
      myNewSkin/
        newskin.css
        newgifs.gif
        ...
  locale/
    US-en/
      navigator.dtd

Para cargar la información del chrome guardada en el paquete del nuevo directorio como el de antes, se puede usar la siguiente url chrome:

chrome://navigator/skin/myNewSkin/newskin.css

que cargará los gráficos de dicho subdirectorio cuando se necesiten:

Apariencia

La apariencia es el conjunto de CSS y gráficos que proporcionan el aspecto o presentan a XUL. XUL por sí mismo contiene muy poca información sobre cómo deben de presentarse los controles en la interfaz. Antes incluso de que se aplique la apariencia global (la cual es cargada en casi cada fichero XUL que se ve en Mozilla y cuya ausencia de los propios ficheros XUL puede hacer que se muestren de modo extraño, sin sentido, invisibles, o todo a la vez), el fichero xul.css es cargado para proporcionar algo de información de presentación muy básica para los controles comunes. Por todo esto, CSS es una parte vital de lo que hace a XUL lo que es, especialmente con el llegada de CSS 2 y sus nuevas capacidades de posicionamiento.

Los cambios de apariencia son más apropiados cuando se trata de cambiar dinámicamente la apariencia general de una aplicación. Pese a que esto aún no existe en el navegador, muy pronto será posible cambiar por completo el aspecto de la aplicación dinámicamente aunque sólo para ampliar la apariencia definida en el global.css principal o en otra apariencia global. Cuando se crean estilos en las etiquetas <tags>, como atributos de estilo para elementos individuales, o en ficheros CSS personalizados se está rompiendo la capacidad de Gecko para dotar de apariencia a la aplicación a la que pertenece el XUL.

Controles

Los controles (widgets en inglés) son las piezas que permiten ser ensambladas para construir un interfaz. Los menús, las barras de herramientas, los botones y las barras de desplazamiento son controles y como tales son piezas de propósito general al igual que las cajas (box) y las cajas de relleno (spring). Dichos controles pueden ser creados y ubicados dentro de un fichero XUL como elementos simples: <menu>, <toolbar>, etc... La sintaxis para estos elementos está basada en su mayoría en XML. De modo colectivo, estos controles son también conocidos como el XPToolkit.

Modelos de objetos: DOM y AOM

El Modelo de Objetos de Documento (DOM) es la representación de un documento como una serie de objetos interactivos mediante código. Cuando un lenguaje de script como JavaScript accede a las diversas partes de un documento HTML, lo hace a través del DOM. Las partes del documento, tales como la cabecera, los enlaces, el cuerpo..., cualquier etiqueta está disponible como nodos cuyos atributos pueden ser leídos y establecidos. Desafortunadamente, existen diferentes modelos de objetos de documento correspondientes a los diferentes tipos de documentos y también a las diferentes nociones propietarias sobre las que un documento debería ser accedido mediante un programa. El W3C ha estandarizado un modelo de objetos de documento en concreto y ya tiene una recomendación candidata para una versión de actualización. Este es el DOM reflejado en XUL y en el navegador Mozilla. El DOM asienta el objeto window en el más alto nivel del árbol de nodos. El objeto window tiene nodos hijos como el objeto document, el objeto history que almacena las páginas que el usuario ha visitado, nodos de marcos, etc... siendo todos ellos accesibles mediante un programa.

Con las dramáticas mejoras en el modelo de objetos y el poder del DOM 2 del W3C, el concepto del DOM se ver forzado más allá del más abstracto DHTML. Dado que cualquier desarrollo web dinámico es dependiente una vez el programa accede al documento web (o a la interfaz XUL), y dado que el DOM es un estándar y las primeras nociones del HTML dinámico no, el término "DOM" es usado como sinónimo por o en lugar de términos como "HTML dinámico" o "DHTML".

AOM significa modelo de objetos de aplicación y es una extensión del DOM hasta la interfaz definida en XUL. Mientras que HTML es reflejado en el DOM en forma de nodos como link , layer e img , XUL es reflejado en el modelo de objetos de aplicación en la jerarquía de los controles XUL: browser, menu, menuitem, etc... El DOM y el AOM forman una especie de evolución, siendo el conjunto total manipulable desde los estándares sobre los que XUL está basado.

Casi sinónimos de XUL

Existe una gran confusión sobre las palabras que comienzan con "X" en el proyecto de código abierto de Mozilla. La sección Arquitectura XP de Mozilla que se verá más adelante describe XPCOM, XPIDL y XPConnect; tres tecnologías relacionadas de alguna forma para acceder al código de la aplicación desde la interfaz. Esta sección explica XUL, XPToolkit y XPFE, que son de algún modo sinónimos y a la vez diferentes.

En pocas palabras, XUL es el lenguaje basado en XML usado para crear interfaces, XPToolkit es el conjunto de controles XUL (menus, toolbars, etc...) utilizados realmente para este propósito: ser los ladrillos de la interfaz, y XPFE es la parte frontal multiplataforma que ha sido creada a partir de XPToolkit.

Las diferencias son significativas: XUL es el universo de elementos, atributos, sintaxis, reglas y relaciones mientras que el XPToolkit es en realidad un counjunto finito de elementos específicos para el interfaz creados en XUL. EL XPFE es lo que ha sido creado fuera del XPToolkit. Una pobre relación análoga para XUL, XPToolkit y XPFE puede ser la que forman HTML, las etiquetas HTML y una página web, respectivamente.

Partes XUL

La gente se confunde a veces con la sintaxis que describe las partes de un control. Para un control como el menú que se muestra a continuación, menu es el elemento y tanto value como id son atributos.

<menu id="file" value="File" >
  <popup>
    <menuitem value="New" onclick="CreateNewDoc()" />
    <menuitem value="Open" onclick="OpenDoc()" />
    <menuitem value="Close" onclick="CloseDoc()" />
  </popup>
</menu>

El elemento da nombre al item, el control, mientras que los atributos describen características de dicho elemento, tales como su nombre, su estilo, etc... En la jerga orientada a objetos, el elemento es análogo al propio objeto mientras que los atributos son como propiedades. Los atributos tienen un valor asociado a él (tales como la cadena "file" para el atributo id en el ejemplo anterior). Nótese que el elemento menu incluye tanto una etiqueta de apertura al principio como una de cierre al final del ejemplo. De alguna forma, el elemento menu engloba tanto al él mismo como a sus hijos, los elementos menuitem y el elemento popup .

Eventos

Los eventos son también origen de confusión para muchos desarrolladores inexpertos. De hecho, ni yo mismo estoy seguro de comprenderlos del todo pero aquí va una explicación simple de lo que son los eventos y de cómo utilizarlos, básicamente, en una interfaz basada en eventos como la creada en XUL. Los eventos son mensajes que son enviados desde un objeto cuando dicho objeto realiza alguna acción. Por ejemplo, un documento provoca el evento load cuando es cargado en un navegador. El evento click es provocado por un botón cuando es pulsado.

Si no se hace nada con estos eventos, entonces probablemente nunca se sabrá nada de ellos. Los documentos serán cargados, los botones serán pulsados y los enlaces serán sobrevolados... y los eventos serán provocados para cada una de esas acciones de modo imperceptible. En cambio si se escriben manejadores de eventos dentro de escuchadores de eventos como se explicará en breve, se podrán usar estos eventos para realizar otras acciones. El uso de eventos para disparar otros acciones más explícitas explica vagamente lo que es un modelo de eventos.

¿Dónde exactamente están estos eventos provocados? ¿Provocados por quién? Los eventos que son lanzados por un objeto, emergen como una burbuja a través del modelo jerárquico que es el DOM (o el AOM) nodo a nodo. Dichos eventos pueden ser manejados en cualquier punto de la jerarquía (incluyendo el mismo nodo en el que es lanzado). Si nadie en un nivel en particular de la jerarquía está interesado en el evento, entonces el evento continúa emergiendo al siguiente nivel superior hasta llegar a lo más alto de la jerarquía.

El término no es usado con frecuencia, pero un escuchador de eventos es un atributo especial de un objeto que escucha sus propios eventos. El documento, por ejemplo, tiene un escuchador de eventos onload para escuchar a su evento load. Los botones XUL tienen escuchadores de eventos onclick. Los escuchadores de eventos son algo realmente útil: en lugar de usarlos se podría detectar cuándo un objeto ha disparado un evento, luego averiguar de qué evento se trataba y luego tratar el evento como respuesta, pero el escuchador de eventos proporciona un mecanismo fácil para escribir manejadores de eventos para eventos tanto comunes como específicos.

Un manejador de eventos es un retal de código que se escribe en respuesta a un evento. Un manejador de evento onload viene a decir que cuando el documento se cargue, el manejador será llamadao. Y el atributo escuchador de evento proporciona un lugar muy apropiado en el que escribir manejadores de eventos (de hecho es tan apropiado que el término manejador de evento es frecuentemente usado para describir tanto al atributo escuchador de eventos como al código manejador de eventos). Para crear un manejador de eventos, sólo hay que escribir el código que se quiere que sea ejecutado dentro del escuchador de eventos apropiado:

<menuitem value="Púlsame" onclick="alert('Evento manejado.')" />

Esto sigue la explicación de antes de que los manejadores de eventos pueden ser escritos para eventos que son lanzados en algún nivel inferior en la jerarquía. Un menubar en XUL, por ejemplo, puede contener manejadores de eventos para los eventos lanzados por sus menuitems hijos.

Arquitectura XP de Mozilla

Obviamente, Mozilla es mucho más que una simple interfaz. Es multiplataforma basado en los estándares y, de algún modo, los manejadores de eventos escritos en JavaScript y que residen en la interfaz XUL se están volviendo muy importantes en el núcleo de la aplicación.

Cosas como interfaces para sockets, edición, correo/noticias, seguridad... Las tecnologías que hacen esto posible son quizá las menos comprendidas del conglomerado de innovaciones que es Mozilla. Además de los programar estas cosas tan importantes en C++ y compilarlas plataforma a plataforma, los arquitectos y desarrolladores de Mozilla utilizan tres tecnologías XP que unen el núcleo con la interfaz.

XPCOM no es un lenguaje de programación sino una aproximación a la programación (en C++) que proporciona un auténtico modelo de objetos de componentes multiplataforma, de donde la tecnología toma su nombre. Basado en COM, XPCOM proporciona un lenguaje e interfaces independientes de la plataforma que otros objetos pueden usar para acceder a sus servicios. XPCOM refuerza las reglas para diseñar y compilar que hacen posible el uso de servicios de un objeto sin conocer nada sobre la implementación.

XPIDL, el lenguaje de definición de interfaces multiplataforma, es un lenguaje en el que estas interfaces asistidas por XPCOM pueden ser descritos. Usar XPIDL para describir las interfaces XPCOM hace que éstas estén disponibles en ficheros de cabecera especiales. Finalmente, XPConnect es la tecnología que conecta estas interfaces XPCOM/XPIDL con JavaScript, el lenguaje de script que utiliza XUL. La unión de estas tres tecnologías multiplataforma se ubica en mitad de una arquitectura que tiene este aspecto:

Autor: Ian Oeschger
Otros documentos: Mozilla Jargon File y Introducción a XUL