Estructura XUL

  • Enlace amigable (slug) de la revisión: Tutorial_de_XUL/Estructura_XUL
  • Título de la revisión: Estructura XUL
  • Id de la revisión: 169631
  • Creada:
  • Creador: Fedora-core
  • ¿Es la revisión actual? No
  • Comentario /* Locales */

Contenido de la revisión

{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}


{{wiki.template('Traducción', [ "inglés", "XUL_Tutorial:XUL Structure", "en" ])}}


Comenzaremos viendo cómo se procesa XUL por parte de Mozilla

Cómo se procesa XUL

En mozilla, XUL se procesa en forma similar al procesamiento de HTML y otros tipos de contenido. Cuando el usuario digita la URL de una página HTML en el campo dirección del navegador, éste busca el sitio web y descarga su contenido. El motor de renderizado de Mozilla toma el contenido en el formato HTML y lo transforma en un árbol de documento. Este árbol se convierte en un conjunto de objetos que pueden mostrarse en la pantalla. CSS, imágenes y otras tecnologías son usadas para controlar la presentación. El procesamiento de XUL es muy similar.

De hecho, en Mozilla, todos los tipos de documento, sin importar si son HTML, XUL o aún SVG son procesados por el mismo código. Esto significa que las mismas propiedades CSS pueden usarse para definir el estilo tanto del HTML como de XUL, y muchas de las características pueden compartirse entre ambos. Sin embargo, hay características que son específicas del HTML como son las formas, y otras que son específicas de XUL como son los overlays (revestimientos). Ya que XUL y HTML se procesan de la misma forma, se pueden cargar desde el sistema de archivos local del usuario, desde una página web, desde una extensión del navegador o desde una aplicación XULRunner.

El contenido de fuentes remotas, sin importar si es HTML, XUL o cualquier otro tipo de documento, está limitado en la clase de operaciones que pueden realizar, por razones de seguridad. Por este motivo, Mozilla proporciona un método para instalar contenido en forma local y registrar los archivos instalados para que formen parte del sistema chrome. Esto permite usar una URL especial llamada la URL chrome. Al acceder a un archivo usando la URL chrome, éstos reciben privilegios para acceder archivos locales, preferencias, marcadores de página y ejecutar otras operaciones privilegiadas. Obviamente, las páginas web no obtienen estos privilegios, a menos que estén firmadas con un certificado digital y el usuario de el permiso para ejecutar estas operaciones.

Este registro en el paquete chrome es la forma cómo las extensiones de Firefox pueden añadir características al navegador. Las extensiones son pequeños paquetes con archivos XUL, Javascript, hojas de estilo e imágenes empaquetados en un sólo archivo. Este archivo puede crearse usando una utilidad ZIP. Cuando el usuario descarga la extensión, ésta es instalada en su máquina. La extensión se ensambla en el navegador usando una característica especial de XUL llamada overlay (revestimiento), la cual permite que se combinen el XUL de la extensión y el XUL del navegador. Para el usuario, puede parecer que la extensión ha modificado al navegador, pero en realidad el código está separado y la extensión puede desinstalarse fácilmente. Por supuesto, no es necesario que los paquetes registrados usen revestimientos. Si no los usan, no pueden accederse desde la interfaz del navegador, pero el usuario aún puede accederlos por medio de la URL chrome, si sabe cuál es.

Las aplicaciones XUL (que no necesiten del navegador) pueden incluir código XUL de la misma forma, pero este código se incluirá como parte de la instalación, en lugar de tener que instalarse en forma separada como una extensión. Sin embargo, este código XUL debe ser registrado en el sistema chrome de tal forma que las aplicaciones puedan mostrar la interfaz.

Vale la pena anotar que el navegador Mozilla realmente es un conjunto de paquetes que contienen archivos XUL, JavaScript y hojas de estilo. Estos paquetes son accedidos usando una URL chrome y tienen privilegios ampliados y trabajan como cualquier otro paquete. Por supuesto, el navegador es más grande y más sofisticado que la mayoría de las extensiones. Firefox, Thunderbird y muchos otros componentes también estan escritos en XUL y se pueden acceder usando la URL chrome. Ud. puede examinar estos paquetes mirando el directorio chrome dónde Firefox o cualquier otra aplicación XUL está instalada.

La URL chrome siempre comienza por 'chrome://'. De la misma forma que la URL 'http://' hace referencia a sitios web remotos accedidos por medio de HTTP y la URL 'file://' hace referencia a archivos locales, la URL chrome hace referencia a los paquetes y extensiones instaladas. En la próxima sección veremos en detalle la sintaxis de la URL chrome. Es importante anotar que si se accede a un contenido a través de una URL chrome, éste gana los privilegios ampliados que se han mencionado anteriormente y que otras clases de URL no tienen. Por ejemplo, una URL HTTP no tiene ningún privilegio especial, y ocurrirá un error si la página web intenta leer un archivo local. Sin embargo, un archivo cargado por medio de una URL chrome podrá leer archivos sin restricciones.

Esta diferenciación es importante. Significa que hay ciertas cosas que el contenido de las páginas web no pueden hacer, tales como leer los marcadores de página del usuario. Esta diferenciación no está basada en la clase de contenido a ser mostrado, sólo en el tipo de URL empleada. Tanto el HTML como el XUL colocados en un sitio web no tienen permisos adicionales, sin embargo si el HTML o el XUL son cargados por medio de una URL chrome tendrán permisos ampliados.

Si Ud. va a usar XUL en un sitio web, debe colocar el archivo XUL en el sitio web tal como lo haría con un archivo HTML, y luego cargar su URL en el navegador. Debe asegurarse que el servidor web esté configurado para enviar los archivos XUL con el tipo de contenido 'application/vnd.mozilla.xul+xml'. Este tipo de contenido es la forma que tiene Mozilla para diferenciar entre HTML y XUL. Mozilla no usa la extensión del archivo, a menos que esté leyendo archivos del disco, o al hacer doble-click en el archivo en su administrador de archivos. Recuerde que el XUL remoto tendrá restricciones significativas sobre lo que podrá hacer.

Mozilla emplea una clase totalmente diferente de objeto documento para el HTML y el XUL, aunque compartan mucha funcionalidad. En Mozilla existen tres clases principales de documentos: HTML, XML y XUL. Naturalmente, el documento HTML se usa para los documentos HTML, el documento XUL se utiliza en los documentos XUL y el documento XML se emplea para otros tipos de documentos XML. Ya que el formato XUL también es XML, el documento XUL es una subclase del documento XML que es más genérico. Existen diferencias sutiles de funcionalidad. Por ejemplo, mientras los controles de una forma en una página HTML se pueden acceder por medio de la propiedad 'document.forms', esta propiedad no está disponible en los documentos XUL ya que XUL no tiene formas en el sentido en que HTML las tiene. De otra parte, características específicas de XUL como los revestimientos y las plantillas sólo están disponibles en los documentos XUL.

Esta diferenciación entre documentos es importante. Es posible usar muchas características de XUL en documentos HTML o XML ya que no son específicas al tipo de documento, sin embargo, otras características requieren el tipo adecuado de documento. Por ejemplo, se pueden usar los tipos de disposición de XUL en otros documentos ya que no dependen del tipo de documento XUL para funcionar.

Para resumir los puntos expuestos anteriormente:

  • Mozilla muestra tanto el HTML como el XUL usando la misma máquina de renderizado y emplea CSS para especificar su presentación.
  • XUL puede cargarse desde un sitio remoto, desde el sistema de archivos local, o ser instalado con un paquete y ser accedido usando una URL chrome. Esto es lo que hacen las extensiones del navegador.
  • Las URL chrome pueden usarse para acceder paquetes instalados y abrirlos con privilegios ampliados.
  • HTML, XML y XUL tienen diferentes tipos de documentos. Algunas características pueden usarse en cualquier clase de documento, mientras que otras son específicas para una clase de documento.

En las próximas secciones describiremos la estructura básica de un paquete chrome que será instalado dentro de Mozilla. Sin embargo, si desea comenzar a construir una aplicación simple, puede saltar a Creando una ventana y dejarlas para después.

Package Organization

Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It will also have one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component will have descriptions of the mail messages list window, the composition window and the address book dialogs.

The packages that are provided with Mozilla are located within the chrome directory, which you will find in the directory where you installed Mozilla. The chrome directory is where you will find all the files that describe the user interface used by the Mozilla browser, mail client and other applications. You will typically put all of the XUL files for an application in this directory, except for extensions which will be installed in the extensions directory for a particular user. Just copying a XUL file into the 'chrome' directory doesn't give the file any extra permissions nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in the next section.

The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.

To further the confusion, there are two other places where the word chrome might appear. The first is the '-chrome' command line argument, and the chrome modifier to the 'window.open' function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.

The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's chrome directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.

There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin and the locale, described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need, and allow other parts, such as the text for different languages, to be downloaded separately.

The three types of chrome packages are:

  • Content - Windows and scripts
    The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a xul extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called editor.xul. Scripts are placed in separate files alongside the XUL files.
  • Skin - Style sheets, images and other theme specific files
    Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.
  • Locale - Locale specific files
    All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.

Content Packages

The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in browser.jar, you will find that it contains a directory structure much like the following:

content
   browser
      browser.xul
      browser.js
      -- other mail XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.

This is easily recognizable as a content package, as the top-level directory is called 'content'. For skins, this directory will usually be called 'skin' and for locales, it will usually be called 'locale'. This naming scheme isn't necessary but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.

The content/browser directory contains a number of files with xul and js extensions. The XUL files are the ones with the xul extension. The files with js extensions are JavaScript files which contain scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.

In the listing above, two files have been shown. There are others of course, but for simplicity they aren't shown. The file browser.xul is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a xul extension. In this case, the package name is 'browser', so we expect to find 'browser.xul'. Some of the other XUL files describe separate windows. For example, the file pageInfo.xul describes the page info dialog.

Many packages will include a contents.rdf, which describes the package, its author and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the .manifest extension in the chrome directory. For instance, browser.manifest describes the browser package.

Several subdirectories, such as bookmarks and preferences, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.

Skins or Themes

The underlying code of Mozilla calls them skins, although the user interface calls them themes, but they both refer to the same thing. The classic.jar file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining classic.jar:

skin
   classic
      browser
         -- browser skin files go here --
      global
         contents.rdf
         -- global skin files go here --.
.
.

Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.

A skin is made up of CSS files and a number of images used to define the look of an interface. The file browser.css is used by browser.xul and contains styles which define the appearance of various parts of the browser interface. Again, note how the file browser.css has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.

Locales

El archivo en-US.jar describe la información del idioma para cada componente, en este caso para US English. Como las pieles (skins), cada idioma contendrá archivos que especifican texto usado por el paquete pero para un idioma concreto. La estructura locale es similar a las otras, por eso no será explicada aquí.

El texto localizado es almacenado en dos tipos de archivos: archivos DTD y archivos de propiedades. Los archivos DTD tienen una extensión dtd y contienen declaraciones de identidad, una para cada cadena de texto usada en una ventana. Por ejemplo, el archivo browser.dtd contiene declaraciones de identidad para cada comando del menú. Además, los atajos de teclado para cada comando también están definidos, ya que deben de ser diferentes para cada idioma. Los archivos DTD son usados por los archivos XUL por eso, en general, tendrás uno para cada archivo XUL. La parte locale también contiene archivos de propiedades, que son similares, pero son usados por archivos script. El archivo browser.properties contiene algunas cadenas localizadas.

Esta estructura nos permite traducir Mozilla o un componente a un idioma distinto sólo añadiendo un nuevo locale para ese lenguaje. No tienes que cambiar la parte de XUL. Además, otra persona puede proporcionar un paquete separado que aplica una piel (skin) o locale a tu parte de contenido, proporcionando soporte de esta manera a un nuevo tema o idioma sin tener que modificar el paquete original.

Otros paquetes

Hay un paquete especial llamado toolkit (o global). Vimos anteriormente el directorio global para skins (pieles). El archivo toolkit.jar contiene el contenido correspondiente para ello. Contiene algunos diálogos globales y definiciones. Además, define la apariencia por defecto y la funcionalidad de varios widgets XUL comunes como son los cuadros de texto y los botones. Los archivos localizados en la parte global de un paquete skin contienen la apariencia por defecto para todos los elementos de la interfaz XUL. El paquete toolkit es usado por todas las aplicaciones XUL.

Añadiendo un paquete

Mozilla coloca los paquetes incluídos con la instalación en la carpeta chrome. Sin embargo, no es necesario colocarlos aquí. Si tienes otro paquete instalado, puede ser colocado en cualquier parte del disco, siempre que un archivo manifest apunte a él. Es una práctica frecuente colocar los paquetes en la carpeta chrome simplemente por ser conveniente, sin embargo sólo funcionarán correctamente desde otro directorio o desde algún lugar de tu red local. No puedes almacenarlos en un lugar remoto, a no ser que el sitio remoto sea montado a través del sistema de ficheros local.

Hay dos carpetas chrome usadas para las aplicaciones XUL, una está instalada en el mismo sitio donde las aplicaciones están instaladas, y la otra es parte del perfil del usuario. Lo primero permite a los paquetes ser compartidos por todos los usuarios, mientras que lo segundo permite la creación de paquetes sólo por un usuario o grupo específico. Extensiones, cuando son instaladas en una carpeta de extensiones diferente, son también normalmente específicas del usuario. Cualquier archivo manifest situado en cualquier carpeta chrome será examinado para ver que los paquetes instalados.

En la siguiente sección, veremos como referirse a un paquete chrome usando chrome URL.

{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}} Interwiki Language Links

{{ wiki.languages( { "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Pomocnik_XUL/Struktura_XUL" } ) }}

Fuente de la revisión

<p>
{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}
</p><p><br>
</p><p>{{wiki.template('Traducción', [ "inglés", "XUL_Tutorial:XUL Structure", "en" ])}}
</p><p><br>
Comenzaremos viendo cómo se procesa XUL por parte de Mozilla
</p>
<h3 name="C.C3.B3mo_se_procesa_XUL"> Cómo se procesa XUL </h3>
<p>En mozilla, XUL se procesa en forma similar al procesamiento de HTML y otros tipos de contenido. Cuando el usuario digita la URL de una página HTML en el campo dirección del navegador, éste busca el sitio web y descarga su contenido. El motor de renderizado de Mozilla toma el contenido en el formato HTML y lo transforma en un árbol de documento. Este árbol se convierte en un conjunto de objetos que pueden mostrarse en la pantalla. CSS, imágenes y otras tecnologías son usadas para controlar la presentación. El procesamiento de XUL es muy similar.
</p><p>De hecho, en Mozilla, todos los tipos de documento, sin importar si son HTML, XUL o aún SVG son procesados por el mismo código. Esto significa que las mismas propiedades CSS pueden usarse para definir el estilo tanto del HTML como de XUL, y muchas de las características pueden compartirse entre ambos. Sin embargo, hay características que son específicas del HTML como son las formas, y otras que son específicas de XUL como son los overlays (revestimientos). Ya que XUL y HTML se procesan de la misma forma, se pueden cargar desde el sistema de archivos local del usuario, desde una página web, desde una extensión del navegador o desde una aplicación XULRunner.
</p><p>El contenido de fuentes remotas, sin importar si es HTML, XUL o cualquier otro tipo de documento, está limitado en la clase de operaciones que pueden realizar, por razones de seguridad. Por este motivo, Mozilla proporciona un método para instalar contenido en forma local y registrar los archivos instalados para que formen parte del sistema chrome. Esto permite usar una URL especial llamada la URL chrome. Al acceder a un archivo usando la URL chrome, éstos reciben privilegios para acceder archivos locales, preferencias, marcadores de página y ejecutar otras operaciones privilegiadas. Obviamente, las páginas web no obtienen estos privilegios, a menos que estén firmadas con un certificado digital y el usuario de el permiso para ejecutar estas operaciones.
</p><p>Este registro en el paquete chrome es la forma cómo las extensiones de Firefox pueden añadir características al navegador. Las extensiones son pequeños paquetes con archivos XUL, Javascript, hojas de estilo e imágenes empaquetados en un sólo archivo. Este archivo puede crearse usando una utilidad ZIP. Cuando el usuario descarga la extensión, ésta es instalada en su máquina. La extensión se ensambla en el navegador usando una característica especial de XUL llamada overlay (revestimiento), la cual permite que se combinen el XUL de la extensión y el XUL del navegador. Para el usuario, puede parecer que la extensión ha modificado al navegador, pero en realidad el código está separado y la extensión puede desinstalarse fácilmente. Por supuesto, no es necesario que los paquetes registrados usen revestimientos. Si no los usan, no pueden accederse desde la interfaz del navegador, pero el usuario aún puede accederlos por medio de la URL chrome, si sabe cuál es.
</p><p>Las aplicaciones XUL (que no necesiten del navegador) pueden incluir código XUL de la misma forma, pero este código se incluirá como parte de la instalación, en lugar de tener que instalarse en forma separada como una extensión. Sin embargo, este código XUL debe ser registrado en el sistema chrome de tal forma que las aplicaciones puedan mostrar la interfaz.
</p><p>Vale la pena anotar que el navegador Mozilla realmente es un conjunto de paquetes que contienen archivos XUL, JavaScript y hojas de estilo. Estos paquetes son accedidos usando una URL chrome y tienen privilegios ampliados y trabajan como cualquier otro paquete. Por supuesto, el navegador es más grande y más sofisticado que la mayoría de las extensiones. Firefox, Thunderbird y muchos otros componentes también estan escritos en XUL y se pueden acceder usando la URL chrome. Ud. puede examinar estos paquetes mirando el directorio chrome dónde Firefox o cualquier otra aplicación XUL está instalada.
</p><p>La URL chrome siempre comienza por 'chrome://'. De la misma forma que la URL 'http://' hace referencia a sitios web remotos accedidos por medio de HTTP y la URL 'file://' hace referencia a archivos locales, la URL chrome hace referencia a los paquetes y extensiones instaladas. En la próxima sección veremos en detalle la sintaxis de la URL chrome. Es importante anotar que si se accede a un contenido a través de una URL chrome, éste gana los privilegios ampliados que se han mencionado anteriormente y que otras clases de URL no tienen. Por ejemplo, una URL HTTP no tiene ningún privilegio especial, y ocurrirá un error si la página web intenta leer un archivo local. Sin embargo, un archivo cargado por medio de una URL chrome podrá leer archivos sin restricciones.
</p><p>Esta diferenciación es importante. Significa que hay ciertas cosas que el contenido de las páginas web no pueden hacer, tales como leer los marcadores de página del usuario. Esta diferenciación no está basada en la clase de contenido a ser mostrado, sólo en el tipo de URL empleada. Tanto el HTML como el XUL colocados en un sitio web no tienen permisos adicionales, sin embargo si el HTML o el XUL son cargados por medio de una URL chrome tendrán permisos ampliados.
</p><p>Si Ud. va a usar XUL en un sitio web, debe colocar el archivo XUL en el sitio web tal como lo haría con un archivo HTML, y luego cargar su URL en el navegador. Debe asegurarse que el servidor web esté configurado para enviar los archivos XUL con el tipo de contenido 'application/vnd.mozilla.xul+xml'. Este tipo de contenido es la forma que tiene Mozilla para diferenciar entre HTML y XUL. Mozilla no usa la extensión del archivo, a menos que esté leyendo archivos del disco, o al hacer doble-click en el archivo en su administrador de archivos. Recuerde que el XUL remoto tendrá restricciones significativas sobre lo que podrá hacer.
</p><p>Mozilla emplea una clase totalmente diferente de objeto documento para el HTML y el XUL, aunque compartan mucha funcionalidad. En Mozilla existen tres clases principales de documentos: HTML, XML y XUL. Naturalmente, el documento HTML se usa para los documentos HTML, el documento XUL se utiliza en los documentos XUL y el documento XML se emplea para otros tipos de documentos XML. Ya que el formato XUL también es XML, el documento XUL es una subclase del documento XML que es más genérico. Existen diferencias sutiles de funcionalidad. Por ejemplo, mientras los controles de una forma en una página HTML se pueden acceder por medio de la propiedad 'document.forms', esta propiedad no está disponible en los documentos XUL ya que XUL no tiene formas en el sentido en que HTML las tiene. De otra parte, características específicas de XUL como los revestimientos y las plantillas sólo están disponibles en los documentos XUL.
</p><p>Esta diferenciación entre documentos es importante. Es posible usar muchas características de XUL en documentos HTML o XML ya que no son específicas al tipo de documento, sin embargo, otras características requieren el tipo adecuado de documento. Por ejemplo, se pueden usar los tipos de disposición de XUL en otros documentos ya que no dependen del tipo de documento XUL para funcionar.
</p><p>Para resumir los puntos expuestos anteriormente:
</p>
<ul><li> Mozilla muestra tanto el HTML como el XUL usando la misma máquina de renderizado y emplea CSS para especificar su presentación.
</li><li> XUL puede cargarse desde un sitio remoto, desde el sistema de archivos local, o ser instalado con un paquete y ser accedido usando una URL chrome. Esto es lo que hacen las extensiones del navegador.
</li><li> Las URL chrome pueden usarse para acceder paquetes instalados y abrirlos con privilegios ampliados.
</li><li> HTML, XML y XUL tienen diferentes tipos de documentos. Algunas características pueden usarse en cualquier clase de documento, mientras que otras son específicas para una clase de documento.
</li></ul>
<p>En las próximas secciones describiremos la estructura básica de un paquete chrome que será instalado dentro de Mozilla. Sin embargo, si desea comenzar a construir una aplicación simple, puede saltar a <a href="es/Tutorial_de_XUL/Creando_una_ventana">Creando una ventana</a> y dejarlas para después.
</p>
<h3 name="Package_Organization"> Package Organization </h3>
<p>Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It will also have one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component will have descriptions of the mail messages list window, the composition window and the address book dialogs.
</p><p>The packages that are provided with Mozilla are located within the chrome directory, which you will find in the directory where you installed Mozilla. The chrome directory is where you will find all the files that describe the user interface used by the Mozilla browser, mail client and other applications. You will typically put all of the XUL files for an application in this directory, except for extensions which will be installed in the extensions directory for a particular user. Just copying a XUL file into the 'chrome' directory doesn't give the file any extra permissions nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in the next section.
</p><p>The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.
</p><p>To further the confusion, there are two other places where the word chrome might appear. The first is the '-chrome' command line argument, and the chrome modifier to the 'window.open' function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.
</p><p>The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's chrome directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.
</p><p>There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin and the locale, described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need, and allow other parts, such as the text for different languages, to be downloaded separately.
</p><p>The three types of chrome packages are:
</p>
<ul>
<li><b>Content</b> - Windows and scripts<br>
The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a xul extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called editor.xul. Scripts are placed in separate files alongside the XUL files.
</li>
<li><b>Skin</b> - Style sheets, images and other theme specific files<br>
Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.
</li>
<li><b>Locale</b> - Locale specific files<br>
All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.
</li>
</ul>
<h3 name="Content_Packages"> Content Packages </h3>
<p>The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in browser.jar, you will find that it contains a directory structure much like the following:
</p>
<pre>content
   browser
      browser.xul
      browser.js
      -- other mail XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.
</pre>
<p>This is easily recognizable as a content package, as the top-level directory is called 'content'. For skins, this directory will usually be called 'skin' and for locales, it will usually be called 'locale'. This naming scheme isn't necessary but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.
</p><p>The content/browser directory contains a number of files with xul and js extensions. The XUL files are the ones with the xul extension. The files with js extensions are JavaScript files which contain scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.
</p><p>In the listing above, two files have been shown. There are others of course, but for simplicity they aren't shown. The file browser.xul is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a xul extension. In this case, the package name is 'browser', so we expect to find 'browser.xul'. Some of the other XUL files describe separate windows. For example, the file pageInfo.xul describes the page info dialog.
</p><p>Many packages will include a contents.rdf, which describes the package, its author and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the .manifest extension in the chrome directory. For instance, browser.manifest describes the browser package.
</p><p>Several subdirectories, such as bookmarks and preferences, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.
</p>
<h3 name="Skins_or_Themes"> Skins or Themes </h3>
<p>The underlying code of Mozilla calls them skins, although the user interface calls them themes, but they both refer to the same thing. The classic.jar file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining classic.jar:
</p>
<pre>skin
   classic
      browser
         -- browser skin files go here --
      global
         contents.rdf
         -- global skin files go here --.
.
.
</pre>
<p>Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.
</p><p>A skin is made up of CSS files and a number of images used to define the look of an interface. The file browser.css is used by browser.xul and contains styles which define the appearance of various parts of the browser interface. Again, note how the file browser.css has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.
</p>
<h3 name="Locales"> Locales </h3>
<p>El archivo en-US.jar describe la información del idioma para cada componente, en este caso para US English. Como las pieles (skins), cada idioma contendrá archivos que especifican texto usado por el paquete pero para un idioma concreto. La estructura locale es similar a las otras, por eso no será explicada aquí.
</p><p>El texto localizado es almacenado en dos tipos de archivos: archivos DTD y archivos de propiedades. Los archivos DTD tienen una extensión dtd y contienen declaraciones de identidad, una para cada cadena de texto usada en una ventana. Por ejemplo, el archivo browser.dtd contiene declaraciones de identidad para cada comando del menú. Además, los atajos de teclado para cada comando también están definidos, ya que deben de ser diferentes para cada idioma. Los archivos DTD son usados por los archivos XUL por eso, en general, tendrás uno para cada archivo XUL. La parte locale también contiene archivos de propiedades, que son similares, pero son usados por archivos script. El archivo browser.properties contiene algunas cadenas localizadas.
</p><p>Esta estructura nos permite traducir Mozilla o un componente a un idioma distinto sólo añadiendo un nuevo locale para ese lenguaje. No tienes que cambiar la parte de XUL. Además, otra persona puede proporcionar un paquete separado que aplica una piel (skin) o locale a tu parte de contenido, proporcionando soporte de esta manera a un nuevo tema o idioma sin tener que modificar el paquete original.
</p>
<h3 name="Otros_paquetes"> Otros paquetes </h3>
<p>Hay un paquete especial llamado toolkit (o global). Vimos anteriormente el directorio global para skins (pieles). El archivo toolkit.jar contiene el contenido correspondiente para ello. Contiene algunos diálogos globales y definiciones. Además, define la apariencia por defecto y la funcionalidad de varios widgets XUL comunes como son los cuadros de texto y los botones. Los archivos localizados en la parte global de un paquete skin contienen la apariencia por defecto para todos los elementos de la interfaz XUL. El paquete toolkit es usado por todas las aplicaciones XUL.
</p>
<h3 name="A.C3.B1adiendo_un_paquete"> Añadiendo un paquete </h3>
<p>Mozilla coloca los paquetes incluídos con la instalación en la carpeta chrome. Sin embargo, no es necesario colocarlos aquí. Si tienes otro paquete instalado, puede ser colocado en cualquier parte del disco, siempre que un archivo manifest apunte a él. Es una práctica frecuente colocar los paquetes en la carpeta chrome simplemente por ser conveniente, sin embargo sólo funcionarán correctamente desde otro directorio o desde algún lugar de tu red local. No puedes almacenarlos en un lugar remoto, a no ser que el sitio remoto sea montado a través del sistema de ficheros local.
</p><p>Hay dos carpetas chrome usadas para las aplicaciones XUL, una está instalada en el mismo sitio donde las aplicaciones están instaladas, y la otra es parte del perfil del usuario. Lo primero permite a los paquetes ser compartidos por todos los usuarios, mientras que lo segundo permite la creación de paquetes sólo por un usuario o grupo específico. Extensiones, cuando son instaladas en una carpeta de extensiones diferente, son también normalmente específicas del usuario. Cualquier archivo manifest situado en cualquier carpeta chrome será examinado para ver que los paquetes instalados.
</p><p>En la siguiente sección, veremos como referirse a un paquete chrome usando chrome URL.
</p><p>{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}
<span class="comment">Interwiki Language Links</span>
</p>{{ wiki.languages( { "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Pomocnik_XUL/Struktura_XUL" } ) }}
Revertir a esta revisión