Get Firefox!

Часть 2. Создаем каркас (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> — это самая важная строка во всем файле. Значение, которое должно быть указано здесь — это уникальный идентификатор вашего расширения. Есть много бесплатных веб-сервисов, которые сгенерируют для вас такой идентификатор. Я рекомендую следующие:

Когда вы сгенерируете собственный ИД, поместите его между тегами <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. И снова довольно просто. Теперь, когда мы разобрались со всей этой скукотищей, давайте оттопыриваться по созданию непосредственно тулбара.