Опубликован: 10.12.2007 | Доступ: свободный | Студентов: 822 / 20 | Оценка: 5.00 / 5.00 | Длительность: 58:33:00
Лекция 12:

Оверлеи и Chrome

< Лекция 11 || Лекция 12: 12345 || Лекция 13 >

12.1. Оверлеи

Система оверлеев довольно проста. Один XUL-документ является мастером. Он - стартовая точка для финального контента. Любой иной XUL документ - это оверлей. Контент оверлея присоединяется, или добавляется, к мастер-документу. Это происходит в оперативной памяти и не оказывает эффекта на исходные файлы.

Оверлей - это XUL-документ, основанный на теге <overlay> вместо тега <window>. Такой файл имеет расширение .xul и является корректным (well-formed) XML, но он не предназначается для самостоятельного использования. Mozilla может показать оверлей сам по себе, но это имеет смысл только для тестирования.

Mozilla также поддерживает стилевые оверлеи. Это обычные CSS2 файлы с расширением .css. Они должны располагаться в директории skin в chrome. Они не используют тег <overlay>.

crome классической Mozilla содержит также так называемые JavaScript- оверлеи. Это не оверлеи в прямом смысле этого слова, это обычные JavaScript файлы с расширением .js. Они присоединяются к оверлею с помощью тега <script> в любом месте оверлей-файла. В этом они не отличаются от обычного XUL.

И мастер, и оверлеи могут содержать синтаксис, специфичный для системы оверлеев.

Система оверлеев имеет два метода, чтобы решить, какие файлы следует сливать вместе. Эти методы называются "сверху-вниз" и "снизу-вверх", потому что первый инициируется мастер- файлом (сверху-вниз), а второй - особой базой данных оверлеев (снизу- вверх).

Система оверлеев использует один механизм слияния файлов. Этот механизм основан на XUL id -атрибуте и имеет несколько незначительных вариаций.

Вот пример работы оверлеев. Незначащий код удален для простоты. Предположим, что мастер-документ взят из листинга 12.2

<window> 
  <box id="one"/> 
  <box id="two"> 
    <label value="Amber"/> 
  </box>
</window>
Листинг 12.2. Пример кода, работающего как мастер.

Предположим далее, что оверлей-документы приведены в листинге 12.3

<overlay>
  <box id="one"> 
    <label="Red"/> 
  </box>
  <box id="three"> 
    <label="Purple"/>  
  </box> 
</overlay> 
<overlay> 
  <box id="two"> 
    <label value="Green"/> 
  </box> 
</overlay>
Листинг 12.3. Пример кода двух оверлеев

Если эти два оверлея сольются с мастер-документом, то результирующий документ представлен в листинге 12.4

<window> 
  <box id="one"> 
    <label="Red"/> 
  <box id="two"> 
    <label value="Amber"/> 
    <label value="Green"/> 
  </box> 
</window>
Листинг 12.4. Документ, объединенный из мастера и двух оверлеев

Если атрибут id в мастер-документе совпадает с id оверлея, дочерние теги оверлея копируются в мастер. Они добавляются к содержанию тега в мастере, если таковое содержание было. Если совпадающего id не обнаруживается (случай Purple ), к мастеру ничего не добавляется. Если не считать некоторых тонких моментов, это и есть вся система оверлеев.

12.1.1. Теги оверлеев

Система оверлеев добавляет к тегам, которые понимает Mozilla, еще два: <?xul-overlay?> и <overlay>. На процесс слияния влияют еще четыре новых атрибута.

12.1.1.1. Тег <?xul-overlay?>

<?xul-overlay?> - это расширение XML, допустимое XML- стандартом. Это инструкция, специфичная для Mozilla. Данная инструкция означает: пожалуйста, добавьте содержание указанного документа к данному документу. Этот тег имеет один специальный атрибут:

href

href можно присвоить значение любого корректного URL, т.е. оверлея, который следует добавить.

Этот тег используется в мастере системой слияния, называемой сверху- вниз. Его можно поместить и в оверлей, в этом случае он сам окажется мастером. Таким образом, используя эту директиву, можно оформить в иерархию целую серию документов.

Mozilla не поддерживает тег <?xul-overlay?> для файлов HTML.

12.1.1.2. Тег <overlay>

Тег <overlay> используется вместо тега <window> в оверлей-документе. Так же как <dialog> или <page>, <overlay> демонстрирует специальное использование XUL контента. В отличие от этих тегов, <overlay> подразумевает неполный документ. Пример приведен в листинге 12.5.

<?xml version="1.0"?>
<overlay xmlns="http://www.mozilla.org/keymaster/
 gatekeeper/there.is.only.xul" id="style-id" > 
  <description>Sample content</description> 
</overlay>
Листинг 12.5. Образец оверлей-документа

Атрибут xmlns по-прежнему требуется. Тег <overlay> имеет три специальных атрибута:

id class style

Все три имеют те же значения, что и в XUL и HTML.

Стили CSS2, основанные на этих атрибутах, могут вести себя необычно. Когда оверлей сливается с мастером, тег <overlay> может полностью передать свое содержание тегам мастера и, следовательно, исчезнуть. В этом случае CSS2 правила, основанные на этом теге, не будут применены.

Существует соглашение присваивать id тегу <overlay> в любом случае. Этот атрибут полезен только если выполняется одно из следующих условий:

Оверлей включает другой оверлей (иерархия оверлеев).

Этот id используется в процессе слияния файлов.

Наоборот, по умолчанию оверлей не следует добавлять, если нет соответствующего id.

Эти три условия - следствия обсуждаемого здесь процесса слияния файлов.

Тег <overlay> необязательно ведет себя как блочный тег. Если мы добавим верстальный атрибут, такой как, например, orient, это будет иметь эффект, только если <overlay> сольется с подходящим тегом в мастере.

12.1.1.3. Тег <overlaytarget>

Тег <overlaytarget> иногда используется, чтобы указать id, соответствующий id в оверлее. Это user-defined тег без какого-либо специального значения.

12.1.2. Поиск оверлеев

Прежде чем система оверлеев сольет что-либо воедино, она должна решить, какие файлы имеют походящее содержание.

Первый метод обнаружения файлов называется "сверху-вниз". Для него требуется, чтобы программист указал в мастере все оверлеи. Этот метод эквивалентен технике включения одного файла в другой, которой обладают многие языки программирования. В C/C++ есть #include, в Perl use и require, а в XUL есть the <?xul-overlay?>.

Метод сверху-вниз дает программисту приложения возможность разбить XUL документ на иерархию отдельных файлов.

Второй метод называется "снизу-вверх". Он требует, чтобы программист указал в базе данных все оверлеи и их мастер-файл. База данных, называемая overlayinfo, опрашивается в момент старта платформы. Этот метод эквивалентен линкующим системам как make(1) and ld(1) в UNIX. Это также напоминает концепции проектов в программных инструментах IDE наподобие Visual Basic.

Метод снизу-вверх дает программисту возможность добавлять содержание к существующему XUL-файлу, не меняя его.

Один мастер-документ может наполняться обоими методами сразу. Листинг 12.1 использует метод сверху-вниз. Однако невозможно сказать, глядя на XUL-документ, используется ли метод снизу-вверх. Это можно узнать, лишь заглянув в базу overlayinfo.

Пакет приложений классической Mozilla включает множество оверлеев, и еще больше может быть добавлено. Таким образом можно улучшить пакет. Наш NoteTaker основан на этой системе, как и большинство экспериментов на сайте http://www.mozdev.org. Подобно этому, оверлеи классической Mozilla могут быть добавлены в отдельное приложение. В любом случае, это пример неоднократного использования XUL-контента.

12.1.2.1. Сверху-вниз

Оверлеи могут быть вызваны прямо из XUL мастер-документа. Это можно сделать в любом XUL-файле. Доступ к chrome не обязателен.

Чтобы присоединить файл-оверлей методом сверху-вниз, нужно включить одну строчку в мастер-документ:

<?xul-overlay href="chrome://mytest/content/Overlay.xul"?>

Обычно эту строчку помещают в начало документа, после <?xml?> заголовка. Если добавляется более одного такого тега, указанные файлы добавляются в порядке этих строк. Если файл указан дважды, он будет присоединен дважды. Указываемые файлы не обязаны находиться в каталоге chrome.

Простой пример сверху-вниз оверлеев можно найти в коде консоли JavaScript. См. файл console.xul в toolkit.jar в chrome. Более сложный пример см. в navigator.xul в comm.jar там же. Это мастер-документ для всего классического браузера. Не на все оверлеи, включаемые в эти приложения, указывается сверху-вниз, но на значительную часть.

Если тег <?xul-overlay?> используется, чтобы загрузить не оверлей-документ, Mozilla может вести себя неадекватно и даже упасть.

12.1.2.2. Снизу вверх

Метод загрузки оверлеев снизу вверх не использует тег <?xul-overlay?>. Вместо этого Mozilla получает информацию из базы данных в chrome. Этот метод требует, чтобы и мастер, и оверлей-документы были установлены в каталоге chrome.

Этот метод позволяет сделать приложения Mozilla расширяемыми. Пакет приложения Mozilla, добавленный в chrome, может встроить свой код в другое приложение.

Самый общий пример дизайна снизу-вверх - это Классический Браузер, включающий пакет navigator, инсталлированный в chromecomm.jar). Многие программисты вносят вклад в его усовершенствование. Когда они разрабатывают плагины к браузеру, они создают оверлеи, которые система слияния снизу-вверх присоединит к окну Классического Браузера. Эти оверлеи содержат элементы GUI, которые появятся в окне браузера. Для нас эти плагины - части привычного интерфейса.

Простой пример - DOM Inspector. Он доступен по умолчанию в классической Mozilla, но не в Netscape 7.0. Нет ни DOM Inspector, ни соответствующего элемента меню. Однако DOM Inspector может быть установлен позже. После его установки появляется элемент в меню Tools | Web Development в окне Навигатора. Это меню содержится в новом оверлее, появившемся при установке приложения DOM Inspector.

Необязательно интегрировать оверлеи с классической Mozilla и ее приложениями. Любое окно XUL может быть мастер-документом.

Чтобы использовать подход снизу-вверх, нужно знать, как работать с RDF.

12.1.2.3. Чтение базы данных оверлеев

База данных оверлеев - это множество директорий и RDF файлов. Она находится в директории chrome/overlayinfo в области установки платформы.

Эта директория порождается из других файлов и может быть уничтожена, когда ее работа завершается. Mozilla читает эту директорию, когда стартует и воссоздает ее, если она не существует. Эта порожденная база данных представляет собой набор поддиректорий. Каждая из них имеет имя пакета, имеющего оверлеи определяемые снизу-вверх. Например, editor - имя пакета, содержащего Composer, так что поддиректория overlayinfo/editor содержит информацию обо всех оверлеях этого пакета. Эта информация не касается оверлеев, определяемых сверху-вниз.

Внутри каждой директории overlayinfo/package есть поддиректория content, в которой лежит файл overlays.rdf. Этот файл эквивалентен make(1) makefile для отдельного пакета. Он действует как множество <?xul-overlay?> инструкций для этого пакета. В нем хранится набор фактов о каждом chrome URL, имеющем оверлеи снизу-вверх. Например, overlayinfo/editor/content/overlays.rdf имеет набор сведений, приведенный в листинге 12.6

<?xml version="1.0"?> 
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
  <Seq about="chrome://editor/content/editor.xul"> 
    <li> chrome://messenger/content/mailEditorOverlay.xul </li> 
    <li> chrome://cascades/content/cascadesOverlay.xul </li> 
  </Seq> 
</RDF>
Листинг 12.6. RDF-факты об оверлеях для Mozilla Composer.

В нем сказано, что при загрузке URL chrome://editor/content/editor.xul нужно загрузить и слить с ним два оверлея, а именно mailEditorOverlay.xul и cascadesOverlay.xul.

Во многих случаях мастер-документ, упоминаемый в этом файле, сам по себе оверлей, один из тех, что грузятся в мастер-документ сверху-вниз. Эта техника слияния имеет своей целью работу с id тегов, описанных в оверлее, но не в самом главном документе. Эти id значимы для промежуточного оверлея, сконструированного специально для этой цели. Данный промежуточный оверлей иногда определяется в overlays.rdf. Он может быть описан в главном документе с помощью одного-единственного id. Сливаясь с главным, он потянет за собой весь свой контент.

Отдельно от базы данных overlayinfo, но все еще в chrome, хранится файл chrome/chrome.rdf. Этот файл нужен для регистра chrome, который отвечает за систему оверлеев. Он содержит ряд конфигурационных сведений. Существует три специфичных для оверлеев предиката:

hasOverlays hasStylesheets disabled

hasOverlays и hasStylesheets используются, чтобы отметить, что XUL-оверлей или CSS оверлей-файлы имеют место для данного пакета. disabled утверждает, что данный пакет не должен принимать оверлеи из внешнего мира, вне самого пакета. Другими словами, оверлеи не могут быть импортированы ни в один документ данного пакета из иных пакетов.

Факт с этими предикатами имеет своим подлежащим URI пакета, такое как urn:mozilla:package:editor, а дополнением строку "true". В этих сообщениях подлежащее не может быть "false". Чтобы придать ему занчение "false", нужно удалить всю строчку. Пример такого сообщения:

<- urn:mozilla:package:editor, hasOverlays, "true" ->

Так что типичная строчка в файле chrome.rdf может гласить:

<Description about="urn:mozilla:package:editor" 
  hasOverlays="true"/>
12.1.2.4. Изменение базы данных оверлеев

База данных оверлеев Mozilla сконструирована так, чтобы поддерживать автодетектирование новых оверлеев. Она тесно связана с инсталляционной системой XPInstall, описываемой в "Система распространения и установки - XPInstall" , "Установка". Несмотря на это ее легко использовать и вручную.

Заглядывая вперед, в систему XPInstall, мы видим следующее:

Прикладные пакеты при установке добавляют строчки в chrome файл, называемый installed-chrome.txt

Mozilla должна быть перезапущена после установки нового пакета, чтобы изменения вступили в силу.

Когда Mozilla стартует, она считывает файл installed-chrome.txt, но только если дата его последнего исправления больше, чем дата, хранящаяся в файле chrome.rdf директории overlayinfo в chrome.

Если installed-chrome.txt прочитан, Mozilla находит все файлы всех пакетов, упомянутые в contents.rdf. Затем на основании информации из contents.rdf воссоздается директория overlayinfo.

Это означает, что все изменения, которые мы можем внести вручную в базу данных оверлеев, исчезнут, если установлен новый пакет. Изменения, внесенные вручную, годятся только для тестирования.

Чтобы добавить новый оверлей в базу данных вручную, нужно остановить платформу и отредактировать файл overlays.rdf пакета, которому принадлежит мастер-документ. Мастер-документ - это подлежащее сообщения, имеющее дополнением тег <Seq>. В Листинге 12.6 приведено все, что необходимо.

Способ сделать эти изменения еще более постоянными - создать файл contents.rdf во время разработки пакета. Этот файл затем добавит необходимые строки в базу overlayinfo при установке пакета. Заметьте, что RDF-контейнры, используемые в файле contents.rdf отличны от контейнеров в файлах overlays.rdf. Когда платформа создает базу overlayinfo, она также пересортирует ее записи по порядку имен пакетов.

Чтобы новые оверлеи были добавлены на постоянной основе, файл contents.rd рассматриваемого пакета должен содержать два добавочных сообщения. Первое - о том, что требуемый мастер-документ теперь имеет оверлей типа снизу-вверх. Другими словами, что отныне мастер-документ требует специальной обработки. Второе сообщение - какие именно существуют оверлеи для данного мастер-файла. Оба сообщения нужно упаковать в правильные контейнеры, чтобы все сработало:

<!-- Указывает документ, получающий оверлей --> 
<Seq about="urn:mozilla:overlays"> 
<li resource="chrome://package1/content/master.xul"/> 
</Seq> 
<!-- указывает оверлей, добавляемый к мастеру --> 
<Seq about="chrome://package1/content/master.xul">
<li> chrome://package2/content/overlay.xul</li> 
</Seq>

Контейнер <Seq about="urn:mozilla:overlays"/> - это служебный список chrome-документов, имеющих оверлеи типа снизу-вверх. Заметьте, что второе сообщение указывает оверлей буквально, а не в виде URI. Это очень важно (см. раздел "Отладка").

Чтобы изменить конфигурационную информацию об оверлеях в chrome.rdf, нужно либо отредактировать ее вручную (временное решение), либо использовать интерфейс nsIXULChromeRegistry, обсуждаемый в разделе "Объекты XPCOM" "Система распространения и установки - XPInstall" . Этот файл можно также модифицировать, используя систему XPInstall, или добавляя сообщения в файлы contents.rdf.

< Лекция 11 || Лекция 12: 12345 || Лекция 13 >