Система распространения и установки - XPInstall
17.3. Технологии установки
В оставшейся части лекции описываются технологии, используемые при удаленной установке.
17.3.1. Применяемые файлы и форматы
Платформа использует несколько различных типов файлов данных. Есть три главных типа этих файлов, и каждый из них имеет свой формат. Это регистры, манифесты и логи.
Регистры - это файлы, доступные для чтения/записи, которые система использует как простую базу данных. Информация об имени приложения, версии и конфигурациях сохраняется в регистрах.
Манифесты - файлы, доступные только для чтения. Они действуют как накладные или списки наличия, другими словами, они описывают то, что имеется в наличии. Mozilla использует Манифесты для перечисления имеющихся XPCOM-компонентов, плагинов, файлов chrome, оверлеев и некоторых аспектов сборочного процесса. Иногда манифесты генерируются из другой доступной информации.
Логи - файлы, доступные платформе только на запись, их можно изучать независимо от процесса установки. Mozilla ведет логи первоначальной установки платформы и последующих удаленных установок. Можно организовать запись в логи расширенной информации, если скомпилировать платформу с опцией --enable-debug.
Форматы, используемые этими файлами, включают формат регистров Mozilla (он описывается ниже) формат файлов Microsoft Windows .ini, RDF и простой текстовый форматы. В таблице 17.1 описываются эти форматы и их использование.
17.3.2. Регистры Mozilla
Регистр Mozilla - файл, по формату напоминающий регистр Microsoft Windows. К нему практически нет доступа, но взглянуть на его устройство полезно, это позволит лучше понять некоторые особенности Mozilla.
Регистр состоит из иерархии ключей, каждый из которых может иметь несколько пар атрибут-значение. Ключи могут быть поименованы иерархически, что по сути является путем к ключу. В корне иерархии ключ "/" и несколько специальных имен, указывающих на важные разделы иерархии. Это эквиваленты именам HKEY_ в Microsoft. Mozilla использует юникодные unicode строки (UTF8-encoded) для имен в регистре.
В отличие от регистра Windows, Mozilla использует прямые слеши (/) в качестве разделителей в полном пути к ключу. Есть и иные отличия.
- В настоящее время Mozilla не имеет утилиты, подобной regedit или regedit32.
- Интерфейс регистров не полностью доступен прикладному программисту.
- Регистры кроссплатформенны и существуют на платформах UNIX, MacOS, и иных.
- Платформа при установке использует более одного регистра
Все регистры Mozilla имеют одинаковую структуру верхних уровней. Все регистры состоят из корня (а именно /) и четырех дочерних директорий:
"/Users/" "/Common/" "/Version Registry/" "/Private Arenas/"
Если при компиляции платформы указан специальный ключ, появляется пятая директория: "/Current User/". В стандартной системе она не присутствует. Ключ, хранимый в одном из четырех путей, может выглядеть, например, так:
"/Version Registry/mozilla.org/Mozilla/XPCom/bin"
Этот ключ не случайно выглядит как имя приложения в регистре - строка после "/Version Registry" именем приложения и является.
Регистр Mozilla - хранилище информации для старта платформы. После того, как платформа стартует, она считывает информацию из регистра. Наиболее смущающий аспект в системе регистров - то, что их несколько, и каждый содержит только часть необходимой информации. Таблица 17.2 разъясняет этот момент.
"Регистр chrome" не является файлом в формате регистров Mozilla. Это термин, которым описывается информация о конфигурации chrome, хранимая в RDF-фалах, включая базу данных оверлеев и дополнительных текстовых файлов, таких как installed-chrome.txt. См. "Оверлеи и Chrome" , "Оверлеи и chrome", для более подробного ознакомления.
Регистр Mozilla недоступен из скрипта install.js, если только не вызывается дополнительный выполняемый файл. К нему можно получить доступ из обычного приложения с помощью следующей пары XPCOM:
@mozilla.org/registry;1 nsIRegistry
Этот интерфейс предоставляет методы для чтения и записи, которые можно использовать для передвижения по дереву ключей регистра. Интерфейс не имеет очевидного способа прочитать (dump) все ключи разом. Ранее применялся один трюк, состоявший в том, чтобы использовать в качестве аргумента nsRegistryKey "магическое" значение 32 (hex 0x20). Это индекс корневого ключа. Имейте в виду, что ни корень, ни его непосредственные четверо "детей" не имеют пар атрибут-значение. Не пытайтесь получить значения этих пар, это имеет смысл делать лишь для боле глубоко лежащих ключей.
17.3.3. Мастера XUL
Иногда приложению требуется провести пользователя по весьма извилистому пути. Установка приложения - как раз такой случай. Обычный способ справиться с этой задачей - снабдить пользователя диалоговым окном, помогающим ему на каждом из шагов. Такие диалоговые окна иногда называют "мастерами" (wizard).
XUL имеет тег <wizard> для создания окна помощи при сложных процессах, подобных установке приложения. <wizard> подобен причудливой комбинации тегов <deck> и <dialog>. Каждый тег <wizard> содержит один или более тегов <wizardpage>. Каждый тег <wizardpage> может содержать произвольный XUL-контент.
Подобно тегу <dialog>, тег <wizard> представляет полное окно и используется вместо тега <window>. Как карты в колоде, теги <wizardpage> сложены в стопку один поверх другого. Тег <wizard> имеет кнопки Next, Back, Cancel и Finish, с помощью которых пользователь может перелистывать страницы, точно так же, как между вкладками (tabs). И <wizard>, и <wizardpage> основаны на связках XBL, хранящихся в файле wizard.xml архива toolkit.jar в chrome.
В архиве toolkit.jar в chrome есть еще несколько файлов с префиксом "wizard". Эти файлы содержат добавочные возможности тега <wizard>, в частности, в форме JavaScript-объекта WizardManager. Если ваше приложение нуждается в нескольких Мастерах, стоит заглянуть в этот код, это поможет сэкономить время. Он позволит создать центральный объект, хранящий всю скриптовую логику Мастеров. Это рекомендуемый способ действий.
На рисунке 17.7 показано окошко, основанное на теге <wizard>. Это окно используется в почтовом клиенте Mozilla при создании нового пользовательского счета.
Эти теги не используются при обычной установке системы, обсуждаемой в данной лекции. Они используются при установке по выбору, установке из chrome и при удаленной установке приложений.
17.3.3.1. Тег <wizard>
Тег <wizard> предоставляет окошку некоторое содержание, логику навигации и обработку событий. Минимум, который должен реализовать программист приложения, - снабдить его недостающим содержанием в виде контента - тегов <wizardpage> (которые обычно состоят из элементов форм и объясняющего текста) и скриптов, проверяющих вводимые данные и реагирующих на действия пользователя. Тег <wizard> имеет следующие специальные атрибуты:
title pagestep firstpage lastpage onwizardnext onwizardback onwizardcancel onwizardfinish
title определяет строку, которая появится в верхней части окна, после слов "Welcome to the".
pagestep определяет, на сколько страниц нужно "перепрыгнуть", если выбраны кнопки Back или Next. Значение по умолчанию - 1 (одна).
firstpage получает значение true, когда показана первая страница.
lastpage получает значение true, когда показана последняя страница.
Остальные атрибуты - это обработчики событий, срабатывающие при нажатии кнопок Next, Back, Cancel, и Finish. Эти обработчики имеют значимые действия по умолчанию. Так же, как для <dialog> и <window>, атрибуты width, height, screenX и screenY не работают в теге <wizard>. Тег <wizard> автоматически получает width="500px", height="380px".
Вдобавок к атрибутам, XBL-определение тега <wizard> имеет методы и свойства, позволяющие имитировать пользовательскую реакцию из скрипта.
На рисунке 17.8 изображено содержание тега <wizard>, если никакого иного содержания программист не определил.
17.3.3.2. Тег <wizardpage>
Тег <wizardpage> подобен тегу <box>. Он используется практически только внутри тега <wizard>. Можно поместить в него любой XUL-контент, но не смешивайте его со встроенной системой навигации Мастера. Лучше добавить несколько страниц, чем усложнять существующие. <wizardpage> имеет следующие атрибуты:
pageid next onpagehide onpageshow onpagerewound onpageadvanced
pageid - идентификатор страницы, отдельный от идентификатора id. Он используется внутренним механизмом Мастера и всегда должен быть определен.
С помощью атрибута next можно нарушить стандартный порядок просмотра страниц Мастера. Он содержит идентификатор pageid. Если он установлен, Мастер больше не следует своей простой стратегии просмотра страниц вперед и назад. Вместо этого любой шаг навигации определяется атрибутом next. Чтобы это работало, нужно присвоить значение свойству next DOM-объекта тега <wizardpage>, а не самому тегу. Если это сделано, вся навигация определяется тегами <wizardpage>, имеющими атрибут next.
Остальные четыре атрибута - обработчики событий. Они срабатывают, когда страницы Мастера появляются и исчезают, и когда пользователь перелистывает страницы. Они не имеют реализации по умолчанию. <wizardpage> - действительно простейшая вещь.