Создание тулбара для Mozilla FireFox - часть 1
Учебные загрузки
В этом учебном пособии мы создадим основу Googlebar Lite.
Чтобы помочь процессу обучения, рабочие версии нашего учебного тулбара доступны для скачивания.
Вам предлагается 2 файла:
- Учебный тулбар в формате XPI -
этот файл является XPI-инсталлятором для тулбара, который мы создадим. Как вы увидите далее, этот файл содержит все исходные коды и прочие необходимые файлы.
Если вы знаете, как распаковывать файлы XPI (а делать это надо зипом - прим.пер.), этого файла вам будет достаточно.
Чтобы установить тулбар, просто сохраните файл к себе на хард, откройте FF и перетащите файл в окошко FF. - Исходный код учебного тулбара.
Этот zip-файл содержит всю файловую структуру нашего учебного тулбара. Как я уже упомянал, все эти файлы доступны в файле XPI. Данный файл позволяет получить доступ ко всему, что нам нужно, более простым способом - без необходимости распаковывать XPI.
Подготовка
Одна из самых замечательных особенностей FF — возможность его настройки. Любой может написать расширение к браузеру, добавив какие-то функции или изменив поведение определенным образом. Но документация о том, как эти расширения создавать, весьма скудна.
Начиная писать GoogleBar Lite, я искал руководства, как создавать тулбары для FF. И хотя мне удалось найти несколько блестящих пособий, рассказывающих о создании расширений вообще, я не нашел ничего относительно создание тулбаров. Поэтому, покопавшись порядком в существующих тулбарах, таких как GoogleBar, Webdevoloper или Ultrabar, я решил взяться за написание собственного руководства, чтобы другим было с чего начать. В конце концов, почему каждый должен изобретать велосипед заново?
В этом руководстве я покажу вам, как создавать расширение и управлять им, описывая, как я создавал Googlebar Lite. Далее мы рассмотрим процесс написания простой версии Googlebar Lite. Я надеюсь, что в итоге полученных знаний хватит для создания собственных тулбаров для FF.
Очень рекомендую скачать и установить этот самый Googlebar Lite, поскольку далее автор периодически обращается к его фукциональности, и гораздо удобнее иметь перед глазами то, о чем он говорит. Иначе можно быстро запутаться — прим. пер.
Устройство файловой структуры.
Расширения для FF требуют определенной файловой структуры, поэтому следует убедиться, что мы выполнили этот шаг верно. Иначе расширение не будет работать так, как мы хотим (скорее всего вообще не будет работать — прим.пер.). Сперва давайте создадим корневую папку с именем нашего расширения. В этом пособии мы будем пользоваться папкой GBLTutorial (пробелы не используем, чтоб потом не париться). Все файлы расширения мы будем размещать в этой папке.
В этой корневой папке надо создать еще одну, которая будет называться chrome (в нижнем регистре), а в папке chrome нужно создать третью, с именем content (опять же, в нижнем регистре). Итак, структура папок должна выглядеть следующим образом:
+- GBLTutorial
+- chrome
+- content
Инструменты, которые нам понадобятся
Перед тем как начать, скажу о нескольких инструментах, которыми нам придется пользоваться на протяжении всего обучения. Все файлы, которые мы будем редактировать вручную (за исключением картинок) — это простые текстовые файлы. Так что убедитесь, что у вас есть хороший текстовый редактор (разумеется, MSWord отдыхает, Wordpad — тоже дурацкая идея, но уже лучше). Желательно, чтоб редактор мог подсвечивать синтаксис XML и автоматически расставлять отступы. Таких полно, например можно использовать Crimson Editor или J Creator (вполне бесплатные).
Второй инструмент, с которым предстоит работать — какой-нибудь ZIP (лично я использую Winzip (лично я тоже =) — прим.пер.)). Он понадобится нам для запаковывания нашего расширения. Рекомендую найти что-нибудь с поддержкой интерфейса командной строки, ибо так проще. Вариантов хватает, выбирайте любой, который больше нравится.
Создаем каркас (Framework)
Аббревиатура RDF расшифровывается как Resourse Description Framework — карскас описания ресурса. RDF-файлы используются для описания структуры расширения. Есть два RDF-файла, представялющих для нас интерес: install.rdf и contents.rdf. Первый сообщает, как наше расширение должно быть установлено в FF, в то время как второй описывает структуру архива с расширением. Опять же, эти данные в этих файлах хранятся в простом текстовом формате, и их можно править любым текстовым редактором, только не забудьте сохранять их с расширением .rdf.
RDF номер раз: install.rdf
Первый файл, который мы создадим, будет называться install.rdf. Этот файл необходимо разместить в корневой директории расширения (в нашем случае — RDFTutorial). Этот файл, также известный как декларация установки (”install manifest”), ответственен за описание нашего расширения для менеджера расширений (extension manager) FF. В нем сообщается с какими версиями FF совместимо наше расширение, и другая важная информация. Все строки, которые нам нужно отредактировать, подсвечены, в то время как строки, общие для всех расширений, отображаются обычным текстом.
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<Description about="urn:mozilla:install-manifest">
<em:creator>Jonah Bishop</em:creator>
<em:description>
A Firefox toolbar tutorial based on Googlebar Lite.
</em:description>
<em:homepageURL>http://www.greenclassic.ru/freescripts/</em:homepageURL>
<em:id>{d5617e3d-5bfe-4be1-a7b8-add67015d92f}</em:id>
<em:name>Dubr Toolbar Tutorial</em:name>
<em:version>1.0</em:version>
<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.0</em:minVersion>
<em:maxVersion>1.0</em:maxVersion>
</Description>
</em:targetApplication>
<em:file>
<Description about="urn:mozilla:extension:file:gbltutorial.jar">
<em:package>content/</em:package>
</Description>
</em:file>
</Description>
</RDF>
Как сообщается в первой строке — это обычный XML-файл. Поэтому формат должен быть понятен для всех, кто когда-либо имел дело с XML. Давайте внимательнее изучим первую секцию, которую нам нужно отредактировать.
В ней представлено множество полезной информации, описывающей наше расширение. Обратите внимание, что порядок представления информации в этом блоке не имеет значения, другими словами, вы можете расположить строки кода так, как вам больше нравится. Я располагаю их в простом алфавитном порядке, поскольку мне так больше нравится (и не впадлу ему это порядок рассчитывать??? — прим.пер.). Первая строка определяет автора расширения (в данном случае — меня), с помощью тега <em:creator>, как вы могли заметить. Далее я привожу описание расширения. Описание — это короткое предложение, сообщающее, что расширение делает, которое появится в менеджере расширений. Третья строка содержит указание на домашнюю страницу расширения (будет по умолчанию использована в диалоговом окне “О расширении”).
Четвертая строка в этом блоке, заключенная в теги <em:id> — это самая важная строка во всем файле. Значение, которое должно быть указано здесь — это уникальный идентификатор вашего расширения. Есть много бесплатных веб-сервисов, которые сгенерируют для вас такой идентификатор. Я рекомендую следующие:
- Andy Hoskinson’s GUID Generator
- A Free GUID Generator Application from Microsoft
- Generate Multiple ID’s at Once
Когда вы сгенерируете собственный ИД, поместите его между тегами <em:id>, как это показано выше. Следующий тег — <em:name> — это просто имя вашего расширения, которое появится в менеджере расширений. Не нужно добавлять номер версии к имени, поскольку для этого есть специальный тег <em:version>. Очевидно, будет необходимо обновлять его всякий раз, когда вы будете готовы представить общественности очередную версию своего творения. Для тех, кто работал со скриптами, не соствит труда автоматизировать этот процесс. Лично я использую в этих целях скрипт на Perl.
Теперь, когда мы указали основные характеристики нашего расширения, давайте посмотрим, что еще нужно поменять в этом файле. Ниже представлен блок кода, с которым надо разобраться.
<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.0</em:minVersion>
<em:maxVersion>1.0</em:maxVersion>
</Description>
</em:targetApplication>
Здесь описывается целевое приложение, для которого наше расширение написано. Обратите внимание, здесь мы видим еще один тег <em:id> — не тот который мы сгенерировали ранее. Он содержит уникальный идентификатор браузера FireFox, и не должен меняться, раз уж мы пишем расширение для FF. Мы также видим два элемента версии: minVersion и maxVersion. Они указывают, с какими версиями FF совместимо наше приложение. В данном примере я просто использую 1.0 в качестве минимальной и максимальной версии. Разработчикам расширений следует обновлять значение maxVersion всякий раз с выходом новой версии браузера.
Обратите внимание, что версия браузера, которую вы указываете, должна следовать общей конвенции. Поэтому версия “1.0 Preview Version” будет воспринята неправильно. Версия FF должна быть указана в следующем формате:
major.minor.release.build[+]
Все поля, кроме “major“, не являются обязательными, поэтому такие версии, как 1, 1.0, 1.0.3 или 1.0.3.20050405 — все допустимы. Для получения дополнительной информации по этому вопросу, обратитесь к статье о присвоении номеров версий на сайте mozilla.org.
Остался последний блок в этом файле, который надо исследовать. Вот он:
<em:file>
<Description about="urn:mozilla:extension:file:gbltutorial.jar">
<em:package>content/</em:package>
</Description>
</em:file>
Этот блок описывает структуру JAR-файла нашего расширения (который мы создадим немного позже). Элемент Description содержит имя JAR-файла в атрибуте about. Вы можете заметить, что в нашем примере имя JAR-файла — gbltutorial.jar. В случае вашего собственного расширения имя этого файла скорее всего будет другим, и оно должно идеально соответствовать имени вашего расширения. Элемент package, показанный в данном примере, отражает структуру JAR-файла. На данный момент у нас есть единственная папка в папке chrome — ее имя “content”. Поэтому мы располагаем только один элемент package, который отражает сей факт. Обратите внимание на слеш после слова “content”. Он необходим, поскольку мы указываем на директорию, которую будет содержать JAR-файл, если слеш не использовать — могут произойти всякие непредвиденные и странные события.
Вот и все, что нужно знать об этом файле. Довольно просто, не так ли? Теперь давайте посмотрим на файл contents.rdf, который не менее прост.
RDF-файл нумер два: contents.rdf
Файл contents.rdf описывает, каким образом хранится содержимое нашего расширения. И снова это просто текстовый документ, который можно создать в любом редакторе. Этот файл необходимо разместить в папке content. Соответственно, после создания этого файла структура папок будет выглядеть как-то так:
+- GBLTutorial/
+- install.rdf
+- chrome/
+- content/
+- contents.rdf
Давайте взглянем на содержимое этого файла. Как и прежде, все строки, в которые нужно вносить изменения, подсвечены.
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:chrome="http://www.mozilla.org/rdf/chrome#">
<RDF:Seq about="urn:mozilla:package:root">
<RDF:li resource="urn:mozilla:package:gbltutorial"/>
</RDF:Seq>
<RDF:Description about="urn:mozilla:package:gbltutorial"
chrome:extension="true" chrome:name="gbltutorial"/>
<RDF:Seq about="urn:mozilla:overlays">
<RDF:li resource="chrome://browser/content/browser.xul"/>
</RDF:Seq>
<RDF:Seq about="chrome://browser/content/browser.xul">
<RDF:li>chrome://gbltutorial/content/gbltutorial.xul</RDF:li>
</RDF:Seq>
</RDF:RDF>
Вы снова можете обнаружить, что это простой XML-файл. И опять мы имеем элемент RDF в качестве корня, но если вы внимательнее посмотрите, то обнаружите, что его атрибуты отличаются от тех, что мы видели в файле install.rdf (изменены пространства имен). Теперь давайте рассмотрим первый блок кода:
<RDF:Seq about="urn:mozilla:package:root"> <RDF:li resource="urn:mozilla:package:gbltutorial"/> </RDF:Seq>
Первое, что мы делаем — обозначаем сборку (package) нашего расширения (которая сделает его уникальным среди всех прочих расширений). Для имени сборки лучше всего использовать имя расширения. В вышепреведенном примере я использовал просто “gbltutorial“.
Далее нужно создать описание сборки нашего расширения:
<RDF:Description about="urn:mozilla:package:gbltutorial" chrome:extension="true" chrome:name="gbltutorial"/>
Вы видите, что мы еще раз указываем имя сборки в качестве первого атрибута элемента. Далее мы покажем, что это действительно расширение, присвоив атрибуту chrome:extension значение true. А потом (снова, а нафига? =) — прим.пер.) укажем имя сборки в атрибуте chrome:name. Имейте ввиду, что из-за ошибки в FF 1.0 значение атрибута chrome:name должно быть указано в нижнем регистре.
Все видимые элементы браузера FF разработаны на языке XUL, и все вместе они называются “chrome”.
http://www.mozilla.org/xpfe/ConfigChromeSpec.html
Следующий блок кода сообщает браузеру, который из chrome-файлов наше расширение будет расширять. Почти всегда это будет файл browser.xul (хотя могут быть и другие, но мы пока сделаем как попроще).
<RDF:Seq about="urn:mozilla:overlays"> <RDF:li resource="chrome://browser/content/browser.xul"/> </RDF:Seq>
Теперь, когда мы сообщили FF, что мы будем расширять, нам нужно сказать, при помощи какого файла мы будем это делать. Следующий блок кода как раз и содержит эту информацию.
<RDF:Seq about="chrome://browser/content/browser.xul"> <RDF:li>chrome://gbltutorial/content/gbltutorial.xul</RDF:li> </RDF:Seq>
Сперва мы указываем, к какому файлу относится расширение, поместив соответствующий chrome-путь в атрибут about. Элемент RDF:li содержит chrome-путь к нашему файлу-надстройке (overlay file), который мы очень скоро начнем писать. В примере выше chrome-путь устроен вот так:
chrome://<packagename>/content/<overlayfilename>.xul
В вашем собственном расширении изменятся packagename и overlayfilename. Все остальное останется на своих местах.
Вот и все, что касается файла contents.rdf. И снова довольно просто. Теперь, когда мы разобрались со всей этой скукотищей, давайте оттопыриваться по созданию непосредственно тулбара.
