В этой главе рассказывается о том, как распространить свое приложение с web-сайта по всему миру. Этим занимается система XPInstall (Cross Platform Install).

Большинство приложений Mozilla создаются для использования. Перед тем, как применять их, нужно инсталлировать эти приложения на свой компьютер. Инсталляция - часть общей проблемы распространения. Mozilla поддерживает несколько стратегий распространения. В данной главе все эти стратегии описаны, но мы сосредоточим внимание на автоматическом распространении приложения с некоторого URL, обслуживаемого обычным web-сервером.

Распространение ПО с удаленного сервера - заманчивая идея еще со времен первых Java-апплетов, а сейчас это часть стратегии .NET. Такой способ делает пользователя или покупателя ПО легко доступным, а стоимость дистрибуции сводит до минимума, что естественным образом согласуется с традиционной архитектурой клиент-сервер. По мере расширения сферы применения Internet аргументы в пользу локально управляемых приложений ослабевают, а значение сервис-провайдеров возрастает, особенно в сфере бизнес-приложений. Даже для локально установленного приложения поток исправлений, ревизий, новостных сообщений делает необходимым создание коммуникационного канала между сервером и пользователем.

Mozilla имеет переносимую инсталляционную систему, которая называется XPInstall. В инструменте вне самой Mozilla, наподобие InstallShield или rpm(1), необходимости нет; XPInstall - все, что вам нужно. XPInstall можно запускать из любого приложения Mozilla вручную, а можно из скрипта.

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

Распространение основывается на основной идее комплекта (bundle). Комплект - это просто набор файлов и скриптов, необходимых для установки приложения. RPMs, тарболы и выполнимые архивы - все это примеры комплектов. Говоря о комплектах, мы здесь будем избегать других похожих терминов, таких как пакет, приложение, инсталлятор и т.п. Все они имеют собственное значение в Mozilla. В Mozilla комплекты - это файлы XPI (суффикс .xpi) или выполнимые файлы. XPI - это сокращение от Cross(X) Platform Install. Файлы XPI - это просто zip-файлы, подразумевающие выполнение нескольких дополнительных соглашений.

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

В случае инсталляции из удаленного источника, XPInstall получает файлы так же, как JVM получает файлы апплета JAR. В отличие от JAR, файлы XPI не содержатся в "песочнице". Они могут быть инсталлированы в любую часть платформы Mozilla и даже в любую часть операционной системы. И та, и другая могут быть сильно повреждены, если комплект плохо сделан. Наиболее безопасная стратегия - инсталлировать приложение только в зону chrome.

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

На диаграмме в начале главы показано, какое влияние имеет XPInstall на платформу Mozilla. Здесь видно, что XPInstall может изменять любые критичные для работающей платформы файлы. По сути дела, вся диаграмма может быть подсвечена, поскольку XPInstall может подменить даже динамически линкуемые библиотеки, другими словами, все, что угодно. Такие обширные замены, однако, редки. Две вещи на диаграмме совсем не указаны - инсталлируемые файлы и собственно XPInstall. Файлы приложения, такие как XUL, CSS, RDF и JavaScript отделены от собственно платформы, но это наиболее часто устанавливаемые файлы. XPInstall - это маленький мирок, потому он и не показан. Его лучше всего рассматривать как специализированный инструмент для закачки файлов, наподобие FTP-клиента или WinAMP.

XPInstall и предоставляет, и использует знакомые нам технологии. Процесс распространения контролируется JavaScript, и есть специальные объекты, этому способствующие. XPInstall предоставляет пользователю последовательность интерактивных окон. Это делается несколькими специальными XUL-тегами.

Мы начнем эту лекцию с описания вариантов установки приложения. Затем опишем процесс удаленной установки и закончим реальным примером используемых технологий.

17.1. Описание инсталляционных стратегий

Любая возможность, которую только можно вообразить, доступна при инсталляции приложений Mozilla. Возможности, рассматриваемые здесь, это: вовсе обойтись без инсталляции, установка вручную, комбинированная установка (piggy-back), собственно установка платформы, - и установка со своим личным инсталлятором. Удаленная установка, главная тема данной главе, подробно обсуждается отдельно.

Простейший способ получить доступ к приложению Mozilla - ничего не инсталлировать вовсе. В этом случае пользователь имеет платформу на локальном компьютере. Приложение грузится из web как серия файлов XUL и всего, что им нужно, то есть оверлеев, стилевых таблиц и скриптов. Чтобы получить документ XUL с web-сайта, просто удостоверьтесь, что тип MIME для файлов .xul имеет значение

application/vnd.mozilla.xul+xml

Если этому не воспрепятствует система безопасности на локальном компьютере, подобное приложение получит такие же права доступа к локальному компьютеру, как и любое иное приложение, установленное в chrome.

Web штука все еще медленная, так что необходимо обратить внимание на производительность. Документы XUL, стилевые таблицы и скрипты кешируются в браузере, так что если в кеше достаточно места, это неплохое начало. Корректные значения параметров в браузере клиента и на сервере могут уменьшить необходимый трафик почти до нуля. На стороне клиента нужно активировать XUL-кеш, а на платформе Windows требуется еще включить функцию Quick Launch (быстрая загрузка приложений). Функция FastLoad загружает платформу в память при старте операционной системы, точно так же, как Internet Explorer. FastLoad становится доступна при первой инсталляции Mozilla или Netscape. Также, файлы XUL могут распространяться по сети как файлы JAR, что тоже улучшает производительность. URL файлов в JAR-архиве имеют вид:

jar:{url}!{path}

Где {url} - адрес архива JAR, а {path} - положение данного файла в нем. Если файл JAR - example.jar - сохранен в корень директории chrome и содержит файл test/sample.xul, то полный путь к файлу sample.xul будет:

jar:resource:/chrome/example.jar!test/sample.xul

Как уже говорилось в главе 12, "Оверлеи и Chrome", схема resource:URL указывает в корень платформы, а chrome:URLs обычно привязана к resource:URLs.

Если используется параметр командной строки -chrome или некоторый параметр, специфичный для данного приложения (как -jsconsole), то стартовавшее приложение XUL может ничем не напоминать браузер вообще. Такие приложения полностью выглядят как локальные.

Если же вернуться к процессу инсталляции, то имеются следующие возможности.

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

Для инсталляции приложения вручную есть немало оснований. Для разработчика это способ тестирования. Для системного администратора - средство проследить за тем, что происходит в системе при работе автоматизированных инструментов. Для системного интегратора используемые здесь ресурсы - рабочие инструменты, объединяемые им затем в бОльшую, интегрированную систему.

Существуют разные типы установки вручную: установка собственно платформы, установка компонентов, приложений и установка системы безопасности. Установка платформы - это установка собственно платформы Mozilla. Она всегда требует выполняемого файла в платформо-зависимом виде, и в этой книге называется собственно установкой. Только после того, как это сделано однажды, возможны другие типы установки.

Установка компонентов вручную добавляет новые компоненты и интерфейсы XPCOM к уже установленной платформе. Эти компоненты становятся доступны всем установленным приложениям. Чтобы инсталлировать новые компоненты и интерфейсы, необходимо:

1. Создать модуль Mozilla. Модуль - это реализация одного или более компонентов и одного или более интерфейсов, так что это задача для программиста. Модулем может быть файл .js на языке JavaScript, или на компилируемом языке, C или C++.
2. Создать компоненты. Для этого нужно превратить модуль в исполняемый код. Для .js ничего делать не требуется. Файлы C/C++ нужно скомпилировать в динамически линкуемую библиотеку, используя сборочную среду Mozilla.
3. Создать интерфейсы. Интерфейс хранится в файле .idl, который автор компонента должен создать. Пропустите XPIDL файл .idl через утилиту xpidlgen, чтобы получить файл библиотеки .xpt. xpidlgen входит в состав сборочной среды Mozilla, так что потребуется либо собрать Mozilla из исходников, либо найти сборку с включенным параметром debug.
4. Скопировать файлы .js и .xpt в директорию компонентов в инсталляционной директории платформы. Либо скопировать туда динамически линкуемую библиотеку. Важно убедиться, что скопированные файлы читаемы (и выполнимы в случае библиотеки).
5. Запустить утилиту regxpcom из инсталляционной директории Mozilla. Данная утилита поставляется вместе с платформой. Это создаст необходимые строки (манифесты) в файлах compreg.dat и xpti.dat.
6. Перестартовать платформу, которая теперь сможет воспользоваться новыми файлами .dat. Компоненты и интерфейсы будут доступны из скриптов.

Исходный код Mozilla содержит пример компонента nsSample и интерфейса nsISample, посмотрите исходный код в директории xpcom/sample.

Установка приложения вручную добавляет новые XUL-файлы в chrome. Эти файлы собраны в пакеты. Чтобы добавить пакет в chrome, необходимо выполнить следующие шаги.

1. Создать пакет. Пакет - это набор файлов, удовлетворяющих стандартной структуре директорий content, skin и locale. Эти файлы можно упаковать в JAR архив, а можно оставить как простую иерархию папок и файлов.
2. Создать и добавить в пакет файл contents.rdf. Пакет еще не пакет без этих файлов. Нужен один файл в директорию content, и по одному в каждую директорию skin и locale.
3. Скопировать пакет или иерархию файлов в директорию chrome.
4. Обновить файл installed-chrome.txt, расположенный в директории chrome. Обычно нужно добавить по строчке на каждую content, locale и skin части пакета.
5. Удалить директорию chrome/overlayinfo, если этот пакет уже устанавливался ранее (а вы сейчас обновляете его). Это обновит систему оверлеев.
6. Перестартовать платформу. Все эти шаги иллюстрировались на примере приложения NoteTaker в первых пяти главах этого курса. В главе 12, "Оверлеи и Chrome", обсуждался механизм регистра chrome, который эти файлы использует.

Строки, добавляемые в installed-chrome.txt должны иметь следующую форму:

skin,install,url,{url}/ 
locale,install,url,{url}/ 
content,install,url,{url}/

где {url} должен указывать на локальную директорию и обычно имеет форму jar: или resource:. Схема resource: указывает на корень платформы Mozilla - родительскую директорию директории chrome. URL локалей должен включать имена локалей, такие как en-US; URL скинов должны включать имена скинов, например, modern.

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

Чтобы создать эти файлы, начните с создания нового пользовательского профиля, с помощью менеджера профилей Mozilla. Скопируйте все файлы профиля, чтобы сохранить оригинал. Затем следует инсталлировать приложение куда нужно. Запустите приложение, используя новый профиль, и не выполняя никаких особенных настроек или других изменений. Каждый раз, когда платформа будет спрашивать о правах на некоторое действие (например, о доступе к файлу с цифровой подписью или форме ввода), дайте такое разрешение. Каждый раз, когда она попросит разрешения запомнить данное решение, соглашайтесь. Пройдя через все аспекты безопасности, закройте приложение и скопируйте все изменившиеся в профиле файлы - сравните их с оригиналом. Это как раз те файлы, которые нужно установить вручную на каждую машину, где будет работать данное приложение. Другой способ - скопировать их в профиль по умолчанию.

И комбинированная (piggy-back), и собственно родная установка платформы требуют использования и модификации сборочного окружения Mozilla. Сборочное окружение здесь не рассматривается, но несколько замечаний все же стоит сделать.

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

Чтобы выполнить эту работу, нужно изменить сборочное окружение Mozilla. К счастью, некоторые такие системы управляются своими же данными, которые можно посмотреть. Можно начать, посмотрев файлы примеров в директории xpinstall/packager. Необходимо внести, по крайней мере, три изменения:

• Манифест, в котором перечисляются все файлы, помещаемые в финальный комплект, нужно обновить. Для этого следует отредактировать файлы, подобные packages-unix.
• Нужно обновить конфигурацию интерактивного подсказчика, инсталлирующего платформу. Эта конфигурация находится в файлах с суффиксами .it.
• Файлы добавочного приложения должны быть доступны, так чтобы их можно было включить. Так или иначе, они должны появиться в директории dist (distribution) создаваемой процессом сборки системы в корне дерева исходников. Это директория, где собираются результаты процесса make. Ручное копирование в нее требуемых файлов - не более чем временная мера, но она может сработать.

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

Собственно инсталляция системы затрагивает самую сердцевину подсистемы XPInstall. Это небольшая часть платформо-зависимого кода. Он не использует XPCOM или иных возможностей Mozilla; это независимая программа, самостоятельно поддерживающая TCP/IP, FTP и HTTP. Чтобы с ней разобраться, требуется поближе познакомиться с исходным кодом Mozilla. Это можно сделать тремя способами:

При инсталляции полной системы, код XPInstall - часть большого архива, содержащего всю платформу и ее приложения. В Microsoft Windows это самораспаковывающийся архив.

При установке так называемой заглушки, распространяемый файл - маленький (заглушка, stub). Он содержит только код XPInstall и некоторую конфигурационную информацию. Когда начинается инсталляция, этот код обращается в сеть и загружает выбранные пользователем компоненты платформы.

При установке приложения код XPInstall используется как специальный инсталлятор конкретного приложения, независимый от основной платформы. При таком использовании XPInstall ведет себя очень похоже на InstallShield или rpm. Это применяется не очень часто и в действительности являет собой разновидность полной инсталляции.

Код XPInstall сам имеет некоторые переносимые между платформами части. Он содержит интерпретатор JavaScript, XUL-подобный код GUI, несколько объектов и систему доступа к операционной системе. Вместе всего этого достаточно извлечь контент из одного или нескольких комплектов XPI и разместить их в файловой системе конкретной ОС. Эта часть XPInstall устанавливает и платформу, и ее приложения в стиле работы InstallShield.

Удаленная установка, подробно рассматриваемая в данной главе, также использует инфраструктуру полной установки. Данная инфраструктура доступна не только в инсталляционном бинарнике, но и просто из запущенной платформы Mozilla. В объектной модели браузера есть некий хук, которому передается файл-комплект XPI, в результате чего начинается его установка.

И, наконец, сами приложения не могут вовсе игнорировать систему XPInstall. Это нестандартная (custom) установка. Технологии XUL и XPCOM обладают достаточными возможностями, чтобы установить приложения из chrome. Если вам действительно нужно создать собственную инсталляционную систему, ничто этому не воспрепятствует. Теги XUL, описываемые ниже в разделе "Технологии установки" позволяют легко создавать диалоговые окна, которые ведут себя подобно стандартному мастеру установки.

17.2. По направлению к удаленной установке

Вообще, удаленная установка - это метод распространения информации, подобный издательской модели традиционных медиа. Создать комплект приложения для удаленной установки через web - значит стать издателем.

Чтобы приложение установилось удаленно, должно произойти несколько событий. Программист приложения, в роли выпускающего инженера, должен написать два скрипта. Конечный пользователь должен согласиться установить приложение. Платформа должна сработать согласно инструкциям.

Удаленная установка основана на использовании URL. Система удаленной установки Mozilla может задействовать схему "file:" так же легко, как и схему "http:". Таким образом, все сделанные здесь замечания относятся и к локальной установке.

17.2.1. Что делает программист

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

17.2.1.1. Присваивание имен и версий

Первый шаг - присвоить приложению необходимые имена. Для работы XPInstall требуется несколько имен.

Эти имена включают: текстовое имя (описание), имя пакета, имя приложения в регистре и версию. Также требуются платформо-зависимые имена. На платформе Microsoft Windows полезен ключ регистра (registry key). Могут понадобиться Macintosh Aliases и Microsoft Windows Shortcuts. Всем этим именам, кроме версии, желательно иметь один и тот же корень. Корень - это просто слово, из которого образуются другие слова. Иные маркеры, такие как броские заголовки (mastheads), бренды, имена исполняемых файлов командной строки, системой XPInstall в явном виде не поддерживаются. XPInstall также не поддерживает и графическое представление приложения, например иконки.

Текстовое имя - это юникодная строка, появляющаяся в диалоговом окне, которое система XPInstall показывает пользователю. Поскольку это юникод, он может содержать среди прочих и символы c, R или TM. XPInstall показывает эту строку латиницей, слева направо, что может являться ограничением для некоторых языков. Вот пример текстового имени:

Frederick's Amazing Shopping Spree System, Gold Version

Имя пакета - это имя, под которым приложение будет установлено в chrome(в случае, если оно устанавливается в chrome). Это имя в кодировке 8-bit extended ASCII, и, для абсолютной переносимости, оно должно быть длиной 8 алфавитно-цифровых символов или меньше (для Unix 14 символов). Поскольку оно используется как имя директории, оно не должно содержать никаких знаков пунктуации (может быть, за исключением знака подчеркивания). Номер версии не нужно включать в имя пакета (например, netscape7), кроме того случая, когда требуется установить две разные версии одного и того же пакета одновременно. Если приложение устанавливается не в chrome, то имя директории для установки должно иметь те же ограничения, что и имя пакета. Пример имени пакета:

fredshop

Имя приложения в регистре - это имя, используемое Mozilla для управления приложением на локальном хосте. Оно используется для управления версиями, установкой и удалением приложения. Регистры Mozilla описываются ниже, в разделе "Технологии установки". Имя регистра выглядит как путь в Unix, за исключением того, что может содержать юникодные символы. Внутри регистра оно хранится в UTF8. Большинство имен регистра следуют такой конвенции:

/Application Publisher/short-name/subproduct

Application Publisher может быть корпоративным или техническим именем. Корпоративное имя может выглядеть как "Alpha Trading Company". Техническое имя может следовать системе, принятой для пакетов Java, например "mozilla.org". Сокращение - это часть имени приложения и обычно оно подобно имени пакета (например, Navigator). Часть subproduct опциональна и используется, когда приложение - часть набора утилит, каждая из которых является фрагментом большого приложения. Пример из Mozilla:

/mozilla.org/Mozilla/JavaScript Debugger/Venkman Chrome

Данный пример показывает, что подраздел может в свою очередь ветвиться. Venkman Chrome - это часть JavaScript Debugger, который в свою очередь - часть Mozilla, собственно приложения.

Если слеша "/" в имени регистра нет, оставшаяся часть рассматривается как подпуть и к ней будет добавлен префикс /mozilla.org/Mozilla/.

Фактически, имя приложения в регистре может быть любым путем, части которого разделены прямым слешем; у первой из последовательности частей нет явно определяемого значения. Это имя не должно соответствовать имени директории; это просто иерархический ключ в стиле ключей Windows Registry. Он имеет ограничение по длине в 2000 символов. Пример:

/Fred's Pyramid Company/Amazing Shopping Spree System/
 Gold Version

Версии приложений Mozilla имеют фиксированный формат; это номер, состоящий из четырех частей. Это четыре 32-битных целых, или строка целых, разделенных точками. Эта строка должна легко конвертироваться в четыре целых числа, она не должна содержать слова "beta" или другой бессмыслицы. Строка версии имеет следующий формат:

"{major}.{minor}.{revision}.{build}"

Главное число (major number) получает значение 0 и может изменяться, если дизайн приложения значительно изменится.

Подчиненное число также получает значение 0 и его увеличение отражает появление в приложении новых свойств. Приложения с меньшим подчиненным числом должны взаимодействовать с данной версией.

"Ревизия" также начинается с 0 и обычно увеличивается при исправлениях ошибок и простейших изменениях. За исключением этих исправлений, все более ранние ревизии должны вести себя идентично данной. "Билд" отражает конкретную попытку собрать приложение из исходного кода. Обычно порождается в процессе сборки и представляет собой уникальный ключ особого типа. Пример полного номера версии:

"1.0.2.20021018"

Существует несколько необязательных конвенций, связанных с этими номерами. Вот некоторые их них:

Номер билда точно идентифицирует каждую конкретную компиляцию или сборку пакета. Это может быть последовательно увеличивающееся число или дата. 32-битное число является достаточно большим, чтобы содержать уникальную последовательность цифр даты, по крайней мере, до 2200 года. Например, для даты 9 A.M., 28 февраля 2009года соответствующее число будет 2003022809. Эту систему построения билда использует Mozilla.

Ядро Linux и некоторые другие продукты используют четные подчиненные (minor) числа для обозначения стабильных релизов, а нечетные - для инновационных. Mozilla не использует эту систему.

Если главное число равно нулю, приложение считается экспериментальным. Не ожидайте от него, что оно сможет работать с предыдущими версиями, и неважно, каким было подчиненное число версии. Всякая совместимость в этом случае должна рассматриваться лишь как случайное совпадение.

17.2.1.2. Создавая мир

Назвать приложение несложно. Сложнее это приложение правильно организовать. В интересах самого разработчика удостовериться, что когда пользователь устанавливает приложение, он имеет достаточно опыта для этого. Потому что когда пользователь решает поставить приложение, он тем самым выражает доверие тому сайту в сети, которое это приложение распространяет. Это доверие еще нужно заслужить, иначе единственным результатом будет лишь плохая репутация.

Итак, второй шаг в подготовке распространения приложения по сети - общая подготовка выпуска приложения (a release review). Чтобы стратегия распространения приложения сработала чисто, инженер, готовящий приложение, должен очень отчетливо понимать, что, собственно, распространяется и куда. Это значит - нужно определить информацию о конфигурации приложения. Документ README, поставляемый вместе с браузером Mozilla, служит примером такой информации, но нужно мыслить и дальше в том же направлении. Необходимо определить три ключевых позиции: исходники (baseline), воздействие (footprint) и требования.

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

Для простых приложений следует просто сделать резервную копию перед каждым релизом.

Воздействие (footprint) - то, как ваше приложение отразится на пользовательском компьютере. Это как минимум список всех файлов, которые будут изменены установленным приложением. Цель выявления воздействия - определить любое место на компьютере, изменяемое установленным или работающим приложением. Когда пользователь номер 52345 звонит, обеспокоенный поломкой компьютера, этот список поможет локализовать проблему.

Примерами обычных элементов воздействия могут быть регистр Windows, иконки на рабочем столе, переменные окружения, глобальные MIME-типы, инсталляционные скрипты. Внутри самой Mozilla работающее приложение может изменять файлы настроек, установки безопасности и локальные MIME-типы. Приложения могут добавлять компоненты в директорию компонентов Mozilla, добавлять специальные бинарные утилиты или модифицировать скрипты командной оболочки, используемые для старта платформы.

Если установочный XPI-комплект затрагивает области вне установочной зоны платформы, не следует автоматически все сваливать под C:\Program Files (Windows) или /usr (UNIX). Это нарушит работу тех IT- специалистов, которые отвечают за конфигурирование и управление системой. Удостоверьтесь, что ваше приложение установит все в одну- единственную папку с именем, выбранным пользователем. Никогда не следует устанавливать файлы в /etc или C:\Windows или C:\Winnt, если есть способ этого избежать.

Для простых приложений воздействие не должно простираться дальше директории chrome и регистров Mozilla. Если пользователь пожелает поместить файлы, генерируемые платформой, куда-либо еще, то это его трудности.

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

Для простых кроссплатформенных приложений требования - не более чем минимальная версия платформы Mozilla.

17.2.1.3. Скрипты

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

Первый скрипт выполняется на обычной web-странице или документе XUL. Для его написания не нужно заботиться о вопросах, связанных с безопасностью. Он выполняется, только если страница или приложение просматривается с помощью технологий самой Mozilla. Остаток страницы приглашает пользователя установить приложение. Второй скрипт, называющийся install.js, выполняется внутри системы XPInstall, где он изолирован и от web, и от XPCOM.

Оба скрипта используют JavaScript-объекты хоста. Объекты, упоминаемые в данной главе, описываются подробно в разделе "Технологии установки".

Первый скрипт называется "триггер-скрипт". С него дистрибуция приложения начинается. JavaScript использует два существующих объекта, а третий должен быть создан. Существующие объекты - это window.InstallTrigger и InstallVersion, который также доступен как window.InstallVersion.

Объект InstallTrigger содержит диагностические методы, а также метод install(), который начинает загрузку файлов XPI и, вероятно, вызывает одну или более копий второго скрипта, install.js. Диагностические методы используются для базовой проверки номеров версий и для проверки того, что система XPInstall имеется в наличии и доступна.

Объект InstallVersion существует для удобства работы, он может сравнить два номера версий приложения и определить, какой из них больше и какие именно из четырех частей номера версии отличаются и чем.

Третий объект, который программист приложения должен создать, имеет следующую форму:

var xpi_container = { 
"Test app part 1" : "URL1", 
"Test app part 2" : "URL2", 
... 
}

Этот объект представляет все файлы XPI, которые в совокупности образуют приложение и передаются методу InstallTrigger.install(). Объект в приведенном примере содержит два свойства, и, таким образом, представляет два файла. Возможно любое число свойств, большее нуля. Поскольку оба имени обоих свойств есть просто строки, они могут быть доступны только как элементы массива:

var url = xpi_container["Test app part 1"];

Каждое имя свойства - текстовое имя компонента приложения, и пользователь будет это имя видеть. Каждое значение свойства - это (относительный или абсолютный) URL, который должен соответствовать файлу XPI. URL может иметь дополнительную строку параметров. Строка параметров начинается со знака вопроса, "?", это тот же формат, что и в строке запроса HTTP GET. Остаток строки также может следовать синтаксису HTTP GET, но может иметь и произвольную форму (хотя это неудачный вариант). Пример URL:

/downloads/apps/mozilla/shopcart/main.xpi?java=yes;flash=no

Это относительный URL, так что Mozilla добавит http: и имя домена. В данном примере код триггера обнаружит наличие Java и отсутствие плагина Flash и передаст эту информацию второму скрипту, install.js в параметрах java и flash. Подстрока параметров передается второму скрипту install.js без дополнительной обработки.

Все эти объекты передаются в функцию, которая обычно вызывается обработчиком onclick, привязанным к линку или кнопке.

В Листинге 17.1 приведен пример скелета такой функции, демонстрирующий большинство возможностей, которые она может включать.

function deploy() { 
  if ( !is_moz_browser() ) { return false; } 
  if ( !window.InstallTrigger.enabled() { return false; } 
  if ( !is_target() ) { return false; } 
  if ( !is_app_version_ok() } { return false; } 
  var error_flag = false; 
  function error_handler(url, err) { 
    error_flag = true; 
  }; 
  calculate_params(); 
  var xpi_container = { ... }; 
    with (window.InstallTrigger) 
      install(xpi_container, error_handler); 
  return !error_flag; 
}

Большинство функций, использованных в скрипте, нужно написать для каждого приложения. Начальная серия проверок остановит процесс установки, если что-то не так с компьютером пользователя или уже установленными приложениями. Функция error_handler() может быть настолько сложной, насколько это необходимо в каждом конкретном случае. Функция calculate_params() подготавливает те параметры, которые будут переданы второму скрипту. Эта информация используется при создании объекта xpi_container. Наконец, вызывается функция install(), реально выполняющая всю работу. Конечно, ничего не произойдет, если отключен JavaScript, или свойство xpinstall.enabled имеет значение false.

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

Второй необходимый скрипт всегда называется install.js. Каждый архив XPI должен содержать такой скрипт. Он отвечает за размещение каждого файла в архиве. Копирование файлов не выполняется самим скриптом. Вместо этого скрипт снабжает систему XPInstall набором инструкций по размещению файлов. Когда все инструкции получены, XPInstall приступает к копированию. XPInstall выполняет инструкции, обрабатывает возникающие ошибки и ведет логи установки. Информация об установке сохраняется для последующего удаления приложения. В любое время до того, как XPInstall начинает свою работу, скрипт install.js может прервать инсталляцию.

Окружение, в котором работает скрипт install.js, существенно ограничивает его возможности. Он работает в контексте отдельного интерпретатора JavaScript и имеет собственный глобальный объект, который не является объектом HTML или XUL окна. Есть всего несколько объектов, с которыми этот скрипт может работать. Вот эти объекты:

Install InstallVersion File FileSpecObject WinProfile WinReg

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

Объект Install имеет полезные свойства. Свойство platform означает операционную систему. Свойство arguments содержит любые параметры, а свойство url содержит полный XPI URL.

Объект Install также имеет полезные методы: initInstall(), инициирующий XPInstall, чтобы тот был готов получить инструкции; cancelInstall(), который полностью останавливает работу; performInstall(), выполняющий инсталляцию согласно полученным инструкциям; и uninstall(), удаляющий приложение. Он также имеет полезные диагностические методы.

Объекты File и FileSpecObject не имеют никакого отношения к файловым объектам XPCOM - это независимая реализация похожих функций. Их можно использовать для работы с файлами в любом месте локального компьютера. Доступны некоторые специальные имена, чтобы это можно было делать на разных платформах. Объект File может выполнять также некоторые тесты и другие вспомогательные задачи.

Объекты WinProfile и WinReg специфичны для Microsoft Windows. WinProfile обеспечивает доступ на чтение и запись к конфигурационным .INI файлам, а WinReg - к Windows Registry.

В зависимости от своего содержания скрипт install.js может потребовать, чтобы платформа была перезагружена; также может понадобиться, чтобы платформа перечитала содержание chrome и плагинов при рестарте. На выполнение скрипта эти побочные эффекты не влияют. Как и триггер-скрипт, скрипт install.js имеет стандартную форму. Она приведена в листинге 17.2.

var TEXT_NAME = "Test Application Release 3.2"; 
var REG_NAME = "/Test Company/Test Application"; 
var VERSION = "3.2.0.1999"; 
var params; 
var rv = SUCCESS;

function prepare() { 
  if ( !(params = parse_args())) return INVALID_ARGUMENTS; 
  if ( is_target() != SUCCESS ) return getLastError(); 

  initInstall(TEXT_NAME, REG_NAME, VERSION); /*  
   -- as many functions like this as required -- */

  if ( schedule_folders()!= SUCCESS) return getLastError(); 
  if ( schedule_files() != SUCCESS ) return getLastError();
  if ( modify_os() != SUCCESS ) return getLastError();
  if ( run_any_programs() != SUCCESS)return getLastError();
  if ( register_chrome() != SUCCESS) return getLastError();

  return SUCCESS; 
} 
rv = prepare(); 
(rv == SUCCESS) ? performInstall() : cancelInstall(rv);

Этот скрипт полагается на сообщения об ошибках, которые вырабатывает и возвращает объект Install, если что-то идет неправильно. Первый шаг - удостовериться, что аргументы, переданные триггер-скриптом, следуют в нужном порядке, и пользовательский компьютер подходит для установки приложения. Если тут все OK, метод initInstall() готовит XPInstall к получению инструкций по установке. Каждая из последующих функций выполняет часть работы по подготовке установки. Наконец, если все идет хорошо, метод performInstall() выполняет все требуемые действия разом. Не показан процесс сохранения информации о процессе установки с помощью метода logComment(), и сообщения о процессе выполнения, посылаемые пользователю с помощью методов alert() или confirm(). Метод prompt() как метод здесь недоступен.

Простейшая версия этого скрипта, полезная для целей тестирования, приведена в листинге 17.3.

var TEXT_NAME = "Test Application Release 3.2"; 
var REG_NAME = "/Test Company/Test Application"; 
var VERSION = "3.2.0.1999";
var rv = SUCCESS; 
function schedule_folders()  { 
  var tree = getFolder("Chrome"); // Special keyword 
  setPackageFolder(tree); 
  addDirectory("chrome"); // topmost directory 
} 
function prepare() { 
  initInstall(TEXT_NAME, REG_NAME, VERSION); 
  if ( schedule_folders()!= SUCCESS) return getLastError(); 
  return SUCCESS; 
} 
rv = prepare(); 
(rv == SUCCESS) ? performInstall() : cancelInstall(rv);

В этом примере функция prepare() обрезана до простейшего состояния и содержит лишь функцию schedule_folders(). Эта функция реализует критически важный шаг сравнения иерархии директорий в файле XPI и локальной файловой системы.

Этот процесс имеет следующую механику. Специальное слово Chrome, одно из немногих ключевых слов, используется, чтобы обозначить директорию chrome в зоне установки платформы. Это ключевое слово не зависит от операционной системы, но остальные слова - платформо-зависимы. Chrome - целевая директория, куда копируется иерархия файлов из файла XPI.

В Листинге 17.3 все фалы в комплекте XPI (кроме install.js) имеют в качестве корневой директории директорию с именем chrome. Эта часть может быть заменена словом "X" или Part или любой иной строкой, потому что это просто "затычка". Все будет работать корректно, если метод addDirectory() заменит ее на то, что нужно в данном конкретном случае.

Если файл XPI имеет в качестве "затычки" слово "chrome", то неплохой выбор для имен файлов внутри нее следующий:

chrome/content/TestApp/TestApp.xul 
chrome/locale/en-US/TestApp/master.dtd 
chrome/skin/classic/TestApp/global.css

Папки в файловой системе сравниваются с папками в комплекте XPI, и этот процесс может повторяться несколько раз в процессе установки. Комплект XPI может иметь несколько деревьев файлов с разными корневыми директориями. Например, если XPI имеет три дерева файлов, каждому дереву ищется соответствующее ему место в локальной файловой системе. Файл XPI может содержать

install.js 
subtree1/file1 
subtree1/file2 
subtree2/file3 
subtree2/file4 
subtree3/file5 
subtree3/file6

Каждое поддерево из двух файлов может быть помещено в различные места одним инсталляционным скриптом.

Наконец, если приложение должно быть удалено, может быть использован метод uninstall() между initInstall() и performInstall(). Он удалит приложение, основываясь на информации об истории установки, хранящейся в регистре Mozilla.

17.2.1.4. Файлы XPI

Файл XPI имеет формат обычного ZIP-файла. Используйте WinZip, pkzip, или подобные им программы на платформе Microsoft Windows; импользуйте zip(1), но не gzip(1), на платформе UNIX. Имена путей в zip-файлах всегда являются относительными.

Есть одно требование к содержанию данного файла: он должен содержать в своем корне файл install.js. Обычной практикой является то, что все остальное в этом файле соответствует структуре директорий в зоне установки платформы. Если структура директорий файла XPI не соответствует реальной файловой структуре, скрипт install.js будет посложнее.

Можно создать цифровую подпись файла XPI. Цифровая подпись выполняется утилитой Netscape SignTool, как и для всех файлов с цифровой подписью в Mozilla, но есть одно ограничение. Цифровая подпись должна быть первым элементом в ZIP-файле XPI. Цифровая подпись - это файл с именем пути META-INF/{signature}, где {signature} - это имя файла с зашифрованной подписью того типа, который поддерживает Mozilla. Удостоверьтесь в том, что утилиты, подобные WinZip, применяют сортировку "original order" или используйте unzip(1) или pkunzip. Подробнее о цифровых подписях и утилите SignTool см.: http://devedge.netscape.com.

На рисунке 17.1 показано содержание комплекта XPI Chatzilla - клиента быстрой связи (instant messaging client). Это ZIP-файл. Данное приложение обычно устанавливается, когда устанавливается комплект приложений Mozilla. Установка выполняется локально, с использованием системы установки Mozilla. Этот файл мог бы быть установлен и удаленно, с использованием механизма удаленной инсталляции.

Корневая директория, в данном случае называемая bin, собирает все необходимые файлы вместе, в одно поддерево. Для каждой платформы в файле XPI есть некоторые особенности, например, в UNIX-версии файлы .ICO заменятся файлами .XBM. Но на всех платформах внутри комплекта есть архив chatzilla.jar, содержащий все chrome-файлы для приложения Chatzilla. Это JAR-файл можно обнаружить в директории chrome на любой машине с установленным набором приложений Mozilla. Файл chatzilla-service.js - новый XPCOM компонент, поставляемый вместе с приложением.

Данный компонент добавляет платформе с установленной Chatzilla новые свойства: опцию командной строки (-chat) и схему URL (irc://).

17.2.1.5. Сокращенный скрипт для файла XPI, не содержащего контента.

Если файл XPI реализует только скин или локаль, скриптинг может быть укорочен. В этом случае не требуется скрипт install.js. В триггер-скрипте вместо install() вызывается installChrome(). Поскольку установка скина или локали не может закончиться неудачей (за исключением того случая, когда на диске не окажется места), триггер- скрипт сводится к одной строчке.

В этом случае файлы, содержащиеся в файле XPI, просто копируются в директорию chrome. Они должны быть JAR-файлами.

17.2.1.6. Сокращенный скрипт для типов MIME

Если файл XPI распространяется web-сервером, он имеет тип MIME

application/x-xpinstall

В этом случае система XPInstall обрабатывает этот файл автоматически. В таком случае нет необходимости в скрипте, привязанном к обработчику события в коде приложения. Любой скрипт install.js из файла XPI будет запущен автоматически.

Программист приложения может вообще избежать использования системы XPInstall. Теги XUL, описываемые в разделе "Технологии установки" позволяют легко создавать диалоговые окна, которые ведут себя как мастер установки.

17.2.2. Что делает пользователь

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

Это HTML-страница, но это мог бы быть и XUL-документ. В таком случае триггер-скрипт был бы несколько сложнее простой кнопки. В данном примере триггер-скрипт реализует установку приложения из трех комплектов XPI. На следующем шаге пользователь видит диалог, изображенный на рисунке 17.3

Этот диалог сообщает пользователю, что, собственно, устанавливается. Если пользователь выберет Cancel, процесс будет остановлен. Если пользователь соглашается, установка начинается и может идти до конца, не предоставляя пользователю новой возможности прекратить процесс. На следующем шаге пользователь видит индикатор прогресса, см. рисунок 17.4.

Перечисленные комплекты загружаются по очереди. Файл install.js, который содержится в каждом комплекте, начинает выполняться сразу после окончания загрузки. Если скрипт не содержит специального кода, он выполняет свою работу без вмешательства пользователя. Если в нем содержатся подсказки или вопросы пользователя, они выглядят как обычные приглашения JavaScript, как показано на рисунке 17.5

Результатом выполнения скрипта install.js может быть либо прерванная, либо неудавшаяся загрузка, либо полная установка XPI-комплекта. Затем пользователь видит сообщение об итогах процесса, см. рисунок 17.6.

Если процесс установки требует, чтобы приложение после установки было запущено заново, пользователь также получит сообщение об этом.

17.2.3. Что делает платформа

Во время удаленной установки платформа управляет всем процессом, получая инструкции из скрипта install.js, выполняет все указанные действия, и сохраняет записи о них. Выполняются следующие шаги:

• Система XPInstall стартует при вызове InstallTrigger.install() или InstallTrigger.installChrome(). Она порождает окна, которые видит пользователь, и управляет ими.
• Выполняется процесс загрузки XPI-архивов в место, предназначенное для хранения временных файлов операционной системы. Кеш Mozilla не используется.
• Если первый файл в архиве является цифровой подписью (это определяется по его полному имени), данная подпись проверяется. Отказ возникает только в том случае, если верификация по требуемому сертификату возможна и не проходит. В этом случае загрузка прекращается. В противном случае процесс продолжается.
• Запускаются по очереди все файлы install.js. Между различными файлами install.js нет координации, они запускаются в порядке их получения. Если какой-либо из XPI-файлов должен удостовериться, что некий другой файл был загружен успешно, это должно быть явно прописано в коде. Этот код может использовать специальный "сигнальный" файл (touch file) или ключ регистра Microsoft Windows, чтобы сообщить о результате.
• Во время выполнения файла install.js записывается информация о шагах с 6 по 11.
• Логи процесса плюс некоторые автоматически создаваемые сообщения записываются в файл chrome/install.log.
• В регистр Mozilla записывается вся информация, которая может понадобиться при удалении приложения.
• В регистр Mozilla записывается информация о том, что данное приложение с данным номером версии отныне существует в системе.
• В файл chrome/installed-chrome.txt записываются результаты всех вызовов registerChrome().
• Записывается, требуется ли заново прочитать chrome или его компоненты.
• Записывается, требуется ли перезагрузка.
• Затем система переходит к выполнению полученных инструкций.
• Распаковываются все требуемые файлы. Если имена файлов или их пути в комплекте XPI не совпадают с прописанными в скрипте, ничего не происходит, и система переходит к выполнению следующей инструкции.
• Выполняются все требуемые операционной системой манипуляции. Если инструкция невыполнима или бессмысленна, генерируется сообщение об ошибке и выполняется следующая инструкция.
• Когда пользователь перезапускает платформу, система проходит через обычную процедуру послеустановочной инициализации: пересчитываются оверлеи chrome, компоненты XPCOM, доступные локали и скины.

Таков в целом процесс удаленной установки. Проверка соответствия версий ложится на плечи прикладного программиста, т.е. на код в на файле install.js.

Иногда система XPInstall задействует оставшуюся часть платформы для выполнения своей работы. Например, использует диалоговое окно предупреждения. Если это необходимо, скрипт, выполняющий свою работу где-то в другом месте платформы, будет блокирован до тех пор, пока 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. См. лекцию 12, "Оверлеи и 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> - действительно простейшая вещь.

17.3.4. Объекты на стороне Web.

Система удаленной установки XPInstall снабжает прикладного программиста двумя объектами, используемыми на обычной HTML или XUL странице: InstallTrigger и InstallVersion. InstallTrigger и InstallVersion - свойства глобального (window) объекта; объект InstallVersion может быть создан методом InstallTrigger.getVersion().

17.3.4.1. InstallTrigger

Таблица 17.3 описывает объект InstallTrigger. Заметьте, что доступны некоторые добавочные константы с тем же смыслом.

17.3.4.2. InstallVersion

Таблица 17.4 описывает объект InstallVersion. Заметьте, что доступны добавочные константы, имеющие то же самое значение, что и основные.

Объект InstallVersion также доступен из скрипта install.js

17.3.5. Объекты на стороне системы XPInstall

Скрипту install.js доступны следующие объекты:

Install InstallVersion FileSpecObject File WinProfile WinReg

Объект InstallVersion описан в разделе "Объекты на стороне web"; остальные описываются здесь.

17.3.5.1. Install

Объект Install - это глобальный объект в скриптовом окружении install.js. Методы этого объекта могут вызываться непосредственно или с префиксом Install. Объект Install - эквивалент свойству window web-страницы.

Объект Install - объект-фабрика, с его помощью можно создать все иные существующие в XPInstall объекты. Он хранит все аргументы, переданные ему триггер-скриптом. Он обеспечивает доступ к глобальной системе номеров сообщений об ошибках, подобной системе C/C++. Он хранит значение текущей директории в процессе установки. Он может совершать основные операции по ведению логов, взаимодействию с пользователем и выполнению программ в операционной системе.

Таблицы 17.5, 17.6, и 17.7 описывают этот объект. Все его свойства доступны только для чтения.

Следующие замечания поясняют таблицу 17.5

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

Значения ошибок - обычно отрицательные целые. Целые между -200 и -299 зарезервированы; значения меньшие -5550 относятся к платформе Macintosh; 0 есть SUCCESS, а 999 - REBOOT_NEEDED. Все значения, генерируемые платформой, имеют соответствующие имена свойств, содержащие константы. В таблице 17.6 эти имена перечислены.

Список корректных селекторов метода gestalt() и их значений можно найти по адресу http://www.rgaros.nl/gestalt/index.html.

Специальные ключевые слова, передаваемые как аргументы методу getFolder(), перечисляются в Таблице 17.7.

Ключевое слово "Program" соответствует корню области установки платформы. Ключевое слово "file:///" соответствует корню локальной файловой системы. Чтобы посмотреть значения специальных ключевых слов на конкретном компьютере, используйте следующую строчку кода:

alert(getFolder(keyword).toString());

17.3.5.2. FileSpecObject

FileSpecObject - объект, подобный значению (value-like object), который передается между методами других объектов в системе XPInstall. Совершать какие-либо действия с этим объектом приходится редко. Он никогда не порождается оператором new в JavaScript. Он имеет лишь одно полезное свойство:

String toString()

Этот метод возвращает путь к папке, уникальный для каждой операционной системы, который представляет объект FileSpecObject.

17.3.5.3. File

Объект Install отвечает за установку и проверку соответствия папок, файлов и поддеревьев файлов. Объект File, по сравнению с ним, отвечает за проверку и точное манипулирование конкретным файлом. Некоторые из методов объекта Install используются для выполнения запланированных задач во время установки. Все методы объекта File выполняются на более позднем этапе.

Всегда используется только один объект File, он доступен как свойство с именем File глобального объекта. Все методы этого объекта доступны как:

File.method_name(args);

Таблица 17.8 описывает объект File.

17.3.5.4. Объект WinProfile

Объект WinProfile, созданные с помощью метода Install.getWinProfile(), может выполнять операции с характерным для Microsoft Windows файлом .INI, например,C:\WINDOWS\WIN.INI. У него есть только два метода:

String getString(String section, String key) 
String writeString(String section, String key, String value)

Поскольку файл .INI имеет расширенный ASCII формат, в него нельзя записывать информацию в юникоде.

17.3.5.5. Объект WinReg

Объект WinReg, созданный с помощью метода Install.GetWinRegistry(), дает доступ к регистру Windows. Операции с регистром выполняются незамедлительно, они не откладываются.

Объект WinReg содержит текущий корневой ключ регистра. По-умолчанию, это HKEY_CLASSES_ROOT.

Имена путей в регистре Windows разделены обратным слешем (\). В скриптах JavaScript обратный слеш нужно писать дважды (\\), противном случае он понимается как управляющий символ.

Таблица 17.9 описывает объект WinReg. Некоторые методы возвращают данные, но многие лишь код статуса. Когда возвращается код статуса, null означает, что платформа Mozilla не может корректно обработать изменения регистра. Обычно это означает проблемы с аргументами метода. Если возвращается не null, значение берется из реальной операции с регистром. Даже когда возвращаемое значение - обычные данные, null означает неудачное действие, в этом случае также, скорее всего, из-за проблем с аргументами. Необходимо всегда проверять возвращаемое значение на null.

17.3.6. Объекты XPCOM

Система XPInstall не дает доступа к интерфейсам XPCOM из скрипта install.js.

Есть, однако, несколько компонентов и интерфейсов за пределами XPInstall, которые дублируют функциональность XPCOM. Если необходима собственная система развертывания приложений, эти приложения и объекты стоит рассмотреть подробнее.

Данная XPCOM пара предоставляет доступ к регистру Mozilla, хотя она не завершена и не очень гибка:

@mozilla.org/registry;1 nsIRegistry

Этот интерфейс работает с различными файлами регистра, как если бы они были одним файлом. Регистр также можно понимать как источник данных RDF. В то время, когда писалась наша книга, этот источник данных RDF еще не был доступен. Будущая XPCOM пара для доступа:

@mozilla.org/registry-viewer;1 nsIRDFDataSource

Другой интерфейс к регистру предоставляется так называемым chrome-регистром. Этот интерфейс позволяет платформе перепрочитать содержание chrome, т.е. оверлеи, скины и локали. Он также может устанавливать в chrome пакеты, скины и локали. Пара XPCOM, предоставляющая эту функциональность:

@mozilla.org/chrome/chrome-registry;1 nsIXULChromeRegistry;1

Для разработчиков на платформе Microsoft Windows представляют интерес следующие два интерфейса:

@mozilla.org/winhooks;1 nsIWindowsRegistry 
@mozilla.org/winhooks;1 nsIWindowsHooks

Эти интерфейсы предоставляют много возможностей по низкоуровневому доступу к Microsoft Windows.

Особняком от этих интерфейсов, работающих с регистрами, стоит много интерфейсов для работы с файлами и сетью, описанными в главе 16, "Объекты XPCOM", в том числе интерфейсы для распаковывания архивов ZIP.

Несколько замечаний относительно собственно объектов XPInstall. Объекты "на стороне Web", InstallTrigger и InstallVersion не имеют полезных интерфейсов XPIDL. Они, однако, имеют Contract ID, зарегистрированные в XPCOM, кроме самой инфраструктуры XPInstall:

@mozilla.org/xpinstall/installtrigger;1 
@mozilla.org/xpinstall/installversion;1 
@mozilla.rg/xpinstall;1

Тем не менее использовать эти Contract ID бессмысленно, поскольку полезных интерфейсов все равно нет. Объекты, доступные в скриптовом окружении install.js, также не представлены в XPCOM. В этом втором случае нет даже и Contract ID для этих объектов.

17.4. Практика: комплектуем Notetaker

В данном разделе "Практика" мы должны упаковать уже работающее приложение Notetaker в XPI-файл и установить его, используя XPInstall. Теоретически, наше приложение должно действовать прямо с удаленного web-сервера, но смешивать локальный контент для приложения с оверлеями, расположенными на web-сервере, бессмысленно. На практике это может даже не работать. Так что займемся установкой приложения, загружаемого с удаленного сервера.

Хотя код приложения уже завершен, кое-что нужно добавить. Наша стратегия: связать все вместе в свете механизма, описанного в данной главе:

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

Приступим.

17.4.1. Подготовка к релизу

Сначала подберем подходящее имя.

Текстовое имя. Выберем "NoteTaker Web Notes". Рекламу прибережем для web-странички, предлагающей приложение пользователю.

Имя пакета. На протяжении книги мы использовали слово "notetaker", пусть так и будет. Тут более 8 символов, что является ограничением для стареньких компьютеров с Microsoft Windows, смиримся с этой небольшой потерей.

Имя приложения в регистре. Это "/Nigel McFarlane/NoteTaker". Если бы наше приложение взяли в главную ветку разработки браузера Mozilla, то имя могло бы быть просто "NoteTaker", что дополнялось бы строкой наподобие "/mozilla.org/Browser/". В этом случае полное имя могло бы быть "/mozilla.org/Browser/NoteTaker". Однако пока такого не случилось.

Номер версии. Нашему приложению не хватало тестирования в реальных условиях, но оно, вроде бы, работает. Назовем его версию 0.9. В полной нотации 0.9.0.0. Можно придумать еще множество усовершенствований и модификаций, но пусть они относятся к версии 1.0

Теперь общая подготовка распространяемого приложения, исходники, воздействие и требования.

Исходники. Все, что обсуждалось в этой книге, и есть основа данного релиза приложения. Я сохранял копии значимого кода в каждой главе в специальной поддиректории главы, и делал инкрементальную резервную копию каждый день и полную копию еженедельно и ежемесячно. Поскольку я заканчиваю сегодня, данная копия содержит все необходимое. Моими исходниками будут исходные файлы этой книги (вариант 1, последняя авторская правка), плюс финальный устанавливаемый XPI-файл, плюс данные бекапа bac-up?. Это бекап хранит также и тестовые файлы и тестовые данные, что очень удобно.

Воздействие. Воздействие приложения NoteTaker невелико. Это лишь три вещи: иерархия папок в директории chrome; регистры Mozilla; последнее - файл notetaker.rdf в текущем профиле пользователя.

Требования. Требования к данному программному обеспечению состоят из нескольких частей. Из-за того, что мы недавно включили объекты XPCOM (file-based streams), нам потребуется платформа Mozilla версии не ниже 1.4, финальный релиз, как минимум. Тестировалось приложение с классическим браузером, не с браузером Mozilla. Приложение переносимо, так что платформа значения не имеет. В ее переносимости есть, однако, некоторые ограничения, которые мы пока не обнаружили. Единственное требование - версия платформы и наличие набора стандартных приложений. Еще нужно заметить, что последующие версии платформы не будут автоматически поддерживаться.

Это все требования со стороны логистики.

17.4.2. Создание файлов поддержки и скриптов

Релиз приложения NoteTaker 0.9 требует кода до и после собственно кода приложения.

Мы включим файл README.txt для разработчиков, которые имеют дело с исходными текстами. Мы напишем его, основываясь на информации из последней рассмотренной темы.

Нам нужен файл contents.rdf для директории notetaker/contents и два регистра. Мы используем один, созданный в главе 2, "Верстка XUL", и включим улучшения, сделанные в главе 12, "Оверлеи и chrome".

Мы хотим показать простейший пример поддержки локалей. Для этого нам нужно иметь файлы contents.rdf и DTD для некоторой локали. Мы используем файл contents.rdf из главе 3, "Статический контент", и создадим простейший файл DTD - ничего не выполняющий.

Нам нужно также дать простейший пример установки скина. Для этого нам нужны файл contents.rdf и файл CSS демонстрационного скина (темы). Мы используем contents.rdf из главе 4, "Первые виджеты и Темы", и создадим простейшую стилевую таблицу, также ничего не выполняющую.

Наконец, нам нужно обеспечить установку. Это задача для одного HTML-файла и двух скриптов. Утилита NoteTaker маленькая и целиком основана на платформе и приложении "классический браузер". Мы надеемся, что скрипты будут простые, а не сложные.

Поскольку файл HTML должен показываться любым браузером, ему лучше быть в высшей степени переносимым, наподобие того, что показан в листинге 17.4.

<html> 
  <head> 
    <script src="deploy.js"/> 
  <body> 
    <h1>NoteTaker Download</h1> 
    <p>The NoteTaker tool adds Web Notes to 
     your Mozilla-based Web browser. Web Notes are placed on 
     top of displayed Web pages. They hold information that you 
     record for your own purposes. 
    </p> 
    <p>Only the Classic Browser, version 1.4, is supported. 
     It is part of the established Mozilla Web application suite. 
     The standalone Mozilla Browser is not yet supported. 
    </p> 
    <p>Download here: <a href="notetaker.xpi" 
      onclick="download(event)">NoteTaker tool 0.9</a> 
    </p> 
  </body> 
</html>

Функция deploy() следует наброску, сделанному в листинге 17.1. В данном случае полный скрипт показан в листинге 17.5. Пуленепробиваемое определение браузера - довольно тягостное дело, здесь мы ограничимся лишь наиболее значимыми альтернативами.

function download(e) { 
  if ( ! deploy() ) 
    alert("NoteTaker 0.9 requires Classic Mozilla 1.4"); 
    e.preventDefault(); 
} 
function is_moz_browser() { 
  return ( 
    window.navigator && 
    window.navigator.userAgent && 
    window.navigator.userAgent.search(/^Mozilla\/5\.0/) != -1 ); 
} 
function is_target() { 
  var agent = window.navigator.userAgent; 
  return ( 
    agent.search(/rv:1\.4/) != -1 && // matches 
    agent.search(/Phoenix/) == -1 && // no match 
    agent.search(/Firebird/) == -1 // no match ); 
} 
function is_app_version_ok() { 
  var it = window.InstallTrigger;
  var result = it.compareVersion( 
    "Nigel McFarlane/NoteTaker", "0.9.0.0"); 
  return ( result == it.NOT_FOUND || 
    Math.abs(result) <= it.REL_DIFF ); 
} 
function deploy() { 
  if ( !is_moz_browser() ) { 
    return false; 
} 
if ( !window.InstallTrigger.enabled() { 
  return false; 
} 
if ( !is_target() ) { 
  return false; 
} 
if ( !is_app_version_ok() } { 
  return false; 
} 
var xpi_container = { 
  "NoteTaker Web Notes" : "notetaker.xpi" 
}; 
with (window.InstallTrigger) 
  install(xpi_container, null); 
  return true; 
}

Здесь нам не требуются никакие параметры, так что эта часть скелета скрипта из Листинга 17.1 не используется. Если пользователь попробует установить NoteTaker не на ту платформу или не на то приложение, мы ему пожалуемся. Здесь нет обработчика событий для функции install(), поскольку мы ничего не можем сделать, если ситуация зайдет в тупик. В большой организации мы можем создать еще одну HTML-страницу, где пользователь может заполнить форму для сообщений об ошибках. А мы положимся на скрипт install.js, который будет содержать полезную диагностику.

Три функции проверок просты. Каждый браузер, чей userAgent начинается с "Mozilla/5.0" может быть браузером mozilla.org. Если userAgent содержит "Firebird" или "Phoenix", это отдельный браузер Mozilla, а не классический браузер, который мы поддерживаем. Тест is_app_version_ok() позволяет установить версию 0.9.1.0 поверх 0.9.0.0. Это даст некоторую гарантию защиты от разработчика, считающего, что отступить назад в номере релиза достаточно безопасно. Это может потребоваться, если в новой версии окажется больше ошибок, чем ожидалось.

Заключительная часть системы установки - скрипт install.js. Листинг 17.6 показывает основную часть этого скрипта, основанного на скрипте, приведенном в листинге 17.2

var TEXT_NAME = "NoteTaker Web Notes"; 
var REG_NAME = "/Nigel McFarlane/NoteTaker"; 
var VERSION = "0.9.0.0"; 
var rv = SUCCESS;

function prepare() { 
  initInstall(TEXT_NAME, REG_NAME, VERSION);

  if ( schedule_files() != SUCCESS ) return getLastError(); 
  if ( register_chrome() != SUCCESS) return getLastError(); 
  return SUCCESS; 
} 
rv = prepare(); 
if (rv == SUCCESS) { performInstall(); 
} else { 
  alert("Installation failed. (Error = " + rv + ")" ); 
  cancelInstall(rv); 
}

Так же, как и в случае триггер-скрипта, install.js упрощен по сравнению со скелетом, приведенным в листинге 17.2. Параметров для проверки нет. Мы предполагаем, что скрипт должен лишь загрузить приложение, если проверяемые условия выполняются. Поскольку NoteTaker - это дополнение к браузеру, у нас нет элементов десктопного меню или пиктограмм. NoteTaker - столь маленькая утилита, что и проверка доступного места на диске бессмысленна. А поскольку утилита написана целиком на JavaScript, у нас нет ни внешних бинарников, ни библиотек, которые требовалось бы обрабатывать. Все, что нам нужно, это корректно разместить содержание файла .XPI и сообщить платформе о существовании нового содержимого в chrome.

Чтобы выполнить эти шаги, нам нужно знать содержание XPI. Заглянем вперед, в раздел "Финальный комплект", и увидим, что содержимое XPI:

install.js 
notetaker.jar 
extras/README.txt 
extras/notetaker.rdf

Собственно приложение располагается в архиве notetaker.jar. Файлы в виртуальной директории extras вряд ли когда-нибудь будут использоваться в работе. Файл README.txt предназначен для того, чтобы любознательные программисты нашли его там и прочитали; файл notetaker.rdf - начальная копия базы данных записей пользователя. Ее нужно скопировать в профиль текущего пользователя.

Листинг 17.7 показывает две функции, отсутствующие в листинге 17.6. Они выполняют необходимые манипуляции с файлами XPI и регистром chrome.

function schedule_files() { 
  addFile(TEXT_NAME, VERSION, "notetaker.jar", 
    getFolder("Chrome"), "notetaker.jar", true); 
  addFile(TEXT_NAME, VERSION, "extras/notetaker.rdf", 
    getFolder("Profile"), "notetaker.rdf", true);

  return SUCCESS; 
} 
function register_chrome() { 
  var jar_root = getFolder("Chrome", "notetaker.jar"); 
  registerChrome(PACKAGE | DELAYED_CHROME, 
   jar_root, "content/notetaker/"); 
  registerChrome(SKIN | DELAYED_CHROME, 
   jar_root, "skin/modern/notetaker/"); 
  registerChrome(LOCALE | DELAYED_CHROME, 
   jar_root, "locale/en-US/notetaker/"); 
  return SUCCESS; 
}

Вызов второй функции addFile() показывает, как можно сравнить путь к любому файлу в файле XPI с любым путем локальной файловой системы. Вызов getFolder() в функции register_chrome() показывает, как корень иерархии папок в файле JAR может быть возвращен как объект. И schedule_files(), и register_chrome() выполняются без обращения к файлу notetaker.xpi. Их вызовы addFile() и registerChrome() выполняются позже, когда стартует функция performInstall().

Это все, что есть в скрипте install.js

17.4.3. Финальный комплект

Теперь мы получили или создали все необходимые нам файлы, и можем, наконец, собрать финальный XPI файл. Он должен содержать как минимум файл install.js (поскольку наше приложение - нечто большее, чем просто скин или локаль), так что начнем с создания zip-архива, содержащего этот файл.

Главным содержанием файла XPI являются коды нашей утилиты NoteTaker. Аккуратный и эффективный способ все организовать - завести единственный архив JAR в директории chrome. Он быстро прочитается на диске, поскольку маленький. Вдобавок, так будет легче манипулировать пакетами, если их число велико. Мы так и сделаем, и поместим его внутрь инсталляционного архива XPI. К сожалению, при работе с JAR-архивами придется основательно потрудиться, по двум причинам.

На протяжении книги мы строили утилиту NoteTaker как набор отдельных файлов и поддеревьев, доступных по адресу resource:/chrome/notetaker. Если бы мы распространяли пакет, организованный именно таким образом, достаточно было бы просто сжать рабочую папку NoteTaker утилитой ZIP и добавить файл install.js. Однако JAR-архивы имеют обратную структуру директорий, чтобы обеспечить быстрый доступ к содержанию. Имеющийся у нас пакет NoteTaker совсем не похож на иерархию директорий, требуемую архивом JAR:

Пакет в chrome <---> JAR архив

notetaker/content  <---> content/notetaker
notetaker/locale/en-US <---> locale/en-US/notetaker 
notetaker/skin/modern <---> skin/moder/notetaker

Единственное решение - сделать копию исходных файлов из chrome в какую-то временную папку и переорганизовать их так, как требуется для JAR-архивов. На систематической основе это делается с помощью Perl, WSH, или shell-скриптом, автоматизирующим процесс реорганизации. Вторую иерархию можно теперь сжать утилитой zip, это и будет файл JAR.

Вторая трудность с JAR-файлами состоит в том, что в больших архивах имеет значение порядок файлов. Наиболее критичные с точки зрения времени доступа файлы должны быть расположены ближе к началу архива, чтобы их легче было найти. Чтобы это сделать, поместите файлы в требуемую JAR-архивом иерархию папок, как раньше. Создайте текстовый файл, перечисляющий все файлы в нужном порядке, и создайте архив на основании этого списка, используя утилиту pkzip (Microsoft Windows) или zip(1) (UNIX). Можно корректно создавать файл JAR и добавляя файлы в архив вручную по одному в нужном порядке, но это утомительно.

На Рисунке 17.9 показан JAR-файл пакета NoteTaker, имеющий некоторый простейший порядок. Content-часть пакета расположена первой, поскольку она используется чаще всего. Фактически, скины и локали в пакете - лишь заглушки, иллюстрирующие, где должны быть помещены подобные вещи. Для столь маленького приложения соблюдать определенный порядок в архиве, вероятно, большого смысла не имеет.

Теперь у нас есть два файла для финального XPI: install.js и notetaker.jar. К ним мы можем добавить файл README и начальный файл notetaker.rdf. Финальный файл XPI (в котором порядок следования файлов не имеет значения, если нет цифровой подписи) показан на рисунке 17.10.

Больше ничего не требуется, кроме как разместить нашу HTML-страничку со ссылкой на файл XPI на web-сайте. На этом мы завершаем пример разработки утилиты NoteTaker.

17.5. Отладка: логи и тестирование

Метод logComment() объекта Install является единственным способом получить диагностические сообщения из файла install.js, если не рассматривать alert(). Сообщения записываются в файл install.log, который сохраняется в корневую область платформы.

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

Если ничего не происходит (или происходит, но не то), хорошая стратегия отладки - упростить процесс установки. Уберите цифровую подпись, затем участки кода, ответственные за проверку версий. Начните с файла XPI, чье содержание всего лишь должно быть скопировано в chrome. Удостоверьтесь, что поддеревья файлов из архива копируются в нужное место. Если у вас нет замысловатой проверки версий, один и тот же XPI-файл может быть безопасно установлен снова и снова - нет необходимости в удалении приложения между установками. В простых случаях безопасней и проще удалить необходимую часть chrome вручную. Только не удалите ничего из стандартных JAR-фалов, идущих вместе с платформой.

Если в приложении есть оверлеи, важно следить, чтобы не была повреждена база данных оверлеев. Если какой-либо из оверлеев имеет синтаксические ошибки или проблемы с совместимостью, не стартует или сама платформа, или начальное окно, так что и установка приложения становится бесполезна. В таком случае удалите базу данных overlayinfo, установленные вами фалы, файл chrome.rdf и строки, добавленные в installedchrome.txt. Затем вновь запустите платформу.

Мы вообще рекомендуем тестировать установку приложения не на той платформе, которая используется для ежедневной работы, а на специальной копии. Эта отдельная платформа может быть "Зоной Краха", предназначенной для экспериментов. На платформе Microsoft Windows лучше даже завести специальный компьютер, поскольку есть лишь одна Mozilla и регистр Windows на хост. Если очень постараться, из скриптов XPInstall можно повредить и сам регистр Windows.

17.6. Итоги

Подсистема Mozilla XPInstall многолика и может использоваться по- разному. Прикладные программисты, которые не хотят изучать процесс компиляции самой системы, видят лишь некоторые ее стороны.

Наиболее привлекательной из технологий XPInstall является удаленная установка. Это действительно удобный механизм распространения программного обеспечения, с низкой стоимостью дистрибуции и возможностью онлайнового обновления. Переносимые свойства системы XPInstall отлично соответствуют переносимым свойствам самой платформы Mozilla. Приложения на основе Mozilla не делят мир на Visual Basic, AppleScript и Perl, но могут быть установлены на наиболее популярные операционные системы одним и тем же способом.

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

Завершением рассмотрения XPInstall заканчивается наша книга о технологиях Mozilla. Сегодня платформа Mozilla - это развитая и богатая возможностями среда разработки приложений. Это очень заметный и очень важный Open Source проект, и его будущее поистине блестяще.

Удачи вам в работе с Mozilla!