Как самому сделать любимый браузер еще лучше
Создание расширений к Mozilla Firefox

Вы наверняка наслышаны о расширениях к Mozilla Firefox, даже если сами предпочитаете пользоваться каким-либо другим браузером. Но знаете ли вы, как создавать эти самые расширения? Нет? А хотите узнать? Тогда эта статья поможет вам войти в мир разработчиков расширений для второго по популярности в мире браузера.

А зачем нам эти расширения?

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

В общем, с "идеологической" частью, думаю, можно закончить и перейти к части технической - то есть, к рассказу о том, как создаются расширения для Mozilla Firefox.

Анатомия расширения

Первое, что стоит себе уяснить - что расширение для Firefox отличается от привычного для большинства разработчиков понимания плагинов для какой-либо программы. Дело в том, что расширение для Firefox, в отличие от плагинов к тем же Total Commander или Adobe Photoshop, не является отдельным исполняемым файлом, в котором реализованы экспортируемые функции специфического вида, которые и используются основным приложением. Что, в общем-то, и понятно, потому что Firefox - программа кросс-платформенная, а за все хорошее в нашем несовершенном мире приходится платить.

Так вот, из чего же состоит расширение для Firefox? Обратимся к полуофициальным источникам (wiki на mozilla-russia.org). В них говорится дословно следующее: "Расширение состоит из 5 частей:

    * RDF-описания файлов, содержащихся в расширении
    * Скрипты (обязательным является скрипт, инсталлирующий расширение в браузер)
    * XUL-файлы - описание интерфейса расширения
    * Локализация - опционально
    * Скины (картинки, содержащиеся в расширении) - опционально"

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

Собственно, всю работу над расширением для Mozilla Firefox (помимо рассмотренного нами выше этапа "обдумывания" этого расширения) можно разделить на две части: программирование на JavaScript'е (написание скриптов, которые будут реализовывать логику работы расширения) и написание всех сопутствующих файлов, которые помогут вашему расширению органично вписаться в среду браузера. Несмотря на то, что на первое место я сейчас поставил программирование, начнем мы со второй части. Почему? Потому что это совершенно не зависящая от программирования работа, которая, тем не менее, требует много внимания со стороны разработчика. Кроме того, если вы правильно напишете код на JavaScript'е, но неправильно оформите сопутствующие файлы, польза от такого расширения все равно будет нулевая. Даже, напротив, оно может начисто "положить" браузер, отбив у пользователя охоту скачивать и устанавливать расширения на долгие годы вперед.

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

Что есть RDF'ы

В общем-то, если не углубляться в подробности, то с точки зрения разработчика расширений для "Огненного лиса", RDF-файлы - это, в общем-то, те же самые XML'и, только записанные специфическим образом и содержащие специфические данные в специфическом же формате. Если вас подробности по поводу RDF как формата не интересуют, вы можете без какого-либо ущерба для себя пропустить этот раздел статьи.

На самом деле, если все-таки немного углубиться, то окажется, что на самом-то деле RDF можно рассматривать едва ли не как полный антипод XML'а. Дело в том, что аббревиатура RDF расшифровывается как Resource Description Framework (по-русски это обычно записывают как "система описания ресурсов"). Как говорится по поводу RDF в одном из официальных руководств по нему, "RDF - это универсальный способ разложения любых знаний на маленькие кусочки. Он задаёт определённые правила касательно семантики, т.е. смысла этих кусочков. Идея состоит в том, чтобы одним простым способом можно было описать любой факт, притом в таком структурированном виде, чтобы его могли обрабатывать компьютерные программы". Фактически, RDF задуман как более продвинутая замена XML, способная обеспечить расширенные возможности работы с данными. Дело в том, что XML, прекрасно подходящий для записи каких-либо утверждений, весьма затрудняет их семантический анализ в силу как раз богатых возможностей записи и неоднозначных вариантов записи одной и той же информации с помощью различных тегов. Хрестоматийный пример - следующая запись:

<car color="red"/>
<car><color>red</color></car>
<car color="#cc"/><color id="cc" shade="red"/>

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

Почему же тогда я выше написал, что с точки зрения разработчика расширений, разница между XML и RDF исчезающе мала? Дело в том, что RDF - достаточно гибкая технология, сумевшая приспособить под свои задачи даже не вполне совершенный, с точки зрения работы с данными, XML. Именно поэтому RDF-документы можно записывать в виде специфических XML-документов (в чем именно состоит специфика, думаю, будет вполне понятно из примера RDF-файла для Firefox, который мы ещё разберем в ходе нашего дальнейшего разговора о написании расширений для этого замечательного браузера).

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

Кстати говоря, если вас заинтересовала тема RDF и вы хотели бы глубже разобраться в отличиях между RDF и XML, могу порекомендовать статью Владимира Шрайбмана "Выражение семантики данных. RDF против XML" (www.citforum.ru/internet/xml/rdf_xml).

Install.rdf

Первый RDF-файл, с которым придется столкнуться любому, кто затеял разработку собственного расширения для Firefox, - это Install Manifest, или, если проще, Install.rdf. Думаю, что из самого названия этого файла понятно, что он нужен для установки расширения в браузер. Именно благодаря ему браузер узнает, совместимо ли расширение с его версией, как обновлять это расширение и т.п.

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

<?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">
  <!- properties ->
</Description>
</RDF>

Как видите, вся "соль" этого файла в загадочном комментарии "properties", который стоит в нем ровно посередине. Что же за загадочные свойства описываются в инсталляционном RDF-файле? Собственно говоря, никакой загадки здесь нет, и полный список свойств, которые могут содержаться в Install.rdf, можно обнаружить по следующему адресу: https://developer.mozilla.org/en/Install_Manifests. Все свойства подразделяются на два типа: обязательные и опциональные. Первые, соответственно, просто обязаны по своей природе присутствовать в Install.rdf, ну а вторые, сами понимаете, появляются там в зависимости от пожеланий и прихотей разработчика. Первых, конечно же, меньше, чем вторых, и все они довольно просты по своей сути.

В общем-то, только необходимые свойства в RDF-файле мы с вами и разберем, потому что разбирать все возможные свойства вряд ли имеет смысл. Но сделаем мы это уже не сейчас, а в одном из следующих номеров "Компьютерных вестей" - сами понимаете, газетная статья имеет естественные ограничения в своём объеме, и, к сожалению, эти ограничения заставляют меня принести свои извинения и пообещать перенести рассказ о создании расширений для Firefox на более позднее время. Надеюсь, в вас еще не перегорит энтузиазм к созданию расширений для "Огненного лиса".

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Как самому сделать любимый браузер еще лучше
Создание расширений к Mozilla Firefox

Изучение премудростей Install.rdf (продолжение)

Как вы, может быть, помните, в прошлый раз мы остановились на знакомстве с файлом Install.rdf, нужным для успешной установки нашего расширения в браузер. Знакомство вышло весьма поверхностным из-за того, что значительную часть статьи я посвятил технологии RDF вообще.

Сейчас речь пойдет об обязательных свойствах, и первое из этих свойств называется Id. Как несложно догадаться, это уникальный идентификатор расширения. Он имеет разный формат в разных версиях Firefox'а. В версии 1.0 это должен был быть полноценный GUID, который можно было сгенерировать, к примеру, с помощью специализированного генератора производства Microsoft (он доступен по адресу www.microsoft.com/downloads/details.asp … laylang=en). Но, начиная с версии Firefox 1.5, идентификаторы приобрели уже "человеческий вид", то есть, их можно записывать в виде "extensionname@organization.tld" (только, естественно, без кавычек и с реальными названиями расширения и его создателя). Конечно, вряд ли вам придется реализовывать в своем расширении поддержку давно не актуальной версии 1.0 "Огненного лиса", но, тем не менее, на всякий случай эту тонкость нужно иметь в виду. Выглядеть же это все должно следующим образом:

<em:id>myextension@mysite.com</em:id>
<em:id>{daf44bf7-a45e-4450-979c-91cf07434c3d}</em:id>

Что ж, с Id все более-менее ясно, поехали дальше. Следующий по списку параметр - version. В нем указывается версия расширения - обратите внимание, версия расширения, а не минимально поддерживаемая версия браузера или что-либо другое. Подробно правила именования версий изложены тут: https://developer.mozilla.org/en/Toolkit_version_format. Если же вы решите не мудрствовать лукаво, а придерживаться "классической" схемы major.minor.release.build, то никаких сложностей с указанием номера версии, по идее, возникнуть не должно. Ну а на практике это все будет выглядеть примерно следующим образом:

<em:version>2.0</em:version>
<em:version>1.0.2</em:version>
<em:version>0.4.1.2005090112</em:version>

Следующее по счету свойство, которое должно быть описано в Install Manifest'е, - это тип дополнения. Поскольку, помимо расширений, в Firefox аналогичным образом устанавливаются темы оформления и локализации браузера, то необходимо явно указать, к чему именно относится ваш пакет. Принадлежность к определенному классу надстроек обозначается соответствующим цифровым кодом - для расширений его значение равняется двум, а все остальное нас пока что не слишком интересует. Ну а вот так это будет выглядеть в RDF'е:

<em:type>2</em:type>

А вот дальше у нас на очереди будет уже более сложное свойство, которое описывает как раз совместимость конкретного расширения с конкретными версиями браузера. И не только браузера - ведь механизм, используемый для установки расширений в Mozilla Firefox, работает ничуть не худшим образом и в почтовике Thunderbird, и в "интернет-комбайне" SeaMonkey, и в календаре Sunbird, и в других программных продуктах. В общем, получается, что свойство targetApplication - едва ли не самое важное в списке всех необходимых для файла Install.rdf свойств. Обратите внимание на то, что, в отличие от рассмотренных нами выше свойств, targetApplication является составным, то есть включает в себя несколько значений, описывающих не только сам поддерживаемый данным расширением программный продукт, но и его версии. Выглядит же все это в RDF'е вот как:

<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>3.0.*</em:maxVersion>
</Description>
</em:targetApplication>

В приведенном выше фрагменте атрибут em:id соответствует GUID'у (идентификатору) соответствующего программного продукта, em:minVersion - минимальной из поддерживаемых расширением версий этого продукта, em:maxVersion - максимально поддерживаемой версии. Полный список GUID'ов и существующих версий можно найти по адресу https://addons.mozilla.org/en-US/firefo … ppversions. Обратите внимание на то, что можно указывать "маски" версий вида 3.0.* и т.п. Возникает резонный вопрос: а что делать, если расширение должно поддерживать несколько продуктов сразу? Хотя мы сейчас говорим только о расширениях для Firefox, тем не менее, никто не мешает использовать их в том же SeaMonkey. Что ж, ответ на этот вопрос прост: сколько у вас есть поддерживаемых приложений, столько и нужно свойств targetApplication в Install.rdf. Кстати, еще одна тонкость: начиная с версии 1.9 движка Gecko, используемого в том числе и в Firefox, можно использовать вместо GUID'а строчку "toolkit@mozilla.org" (без кавычек, конечно же), и тогда вы избежите составления длинного списка targetApplication'ов, потому что автоматически расширение будет считаться совместимым со всеми версиями всех приложений, использующими движок указанных версий.

Ну вот мы, наконец, дошли до последнего обязательного свойства в Install.rdf. Оно называется просто - name. Это название вашего расширения, которое пользователь будет видеть при загрузке и инсталляции. Вот оно какое:

<em:name>My Extension</em:name>

Ну вот, собственно, и все обязательные для Install Manifest'а свойства. Обо всех остальных (а вы наверняка захотите включить некоторые из них в этот файл), напомню, можно узнать по адресу https://developer.mozilla.org/en/Install_Manifests.

Иконка

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

Само создание иконки - тема, выходящая далеко-далеко за рамки данной статьи. Да и не в этом, в общем-то, дело - просто не всякому разработчику хватит художественных способностей для создания действительно качественной и привлекательной внешне иконки. Что касается чисто технической стороны вопроса, то, в общем случае, иконка описывается также в Install.rdf'е, но для версий Mozilla Firefox, начиная с 3.6 (собственно, речь не столько об этом браузере этой версии, сколько о движке Gecko версии 1.9.2 или новее), вполне достаточно вложить в XPI-архив (о его комплектовании мы еще будем говорить дальше подробнее) иконку в формате PNG, имеющую название Icon.png.

XUL

Что ж, создав Install Manifest и задумавшись о необходимости поиска отражающей сущность создаваемого дополнения красивой иконки, можно перейти к главному. А главное в случае написания расширений для Mozilla Firefox - это XUL. Пусть эта аббревиатура и кажется не очень красивой, с точки зрения русскоязычного человека, именно с ней (или, вернее, с тем, что за ней скрывается) мы с вами и будем иметь дело в процессе создания расширений для "Огненного лиса".

Расшифровывается XUL как XML User Interface Language, то есть, примерно как "XML-язык пользовательского интерфейса". Фактически, XUL - это то, на чем написан сам интерфейс браузера Firefox, и, собственно, именно по этой причине XUL и приходится использовать разработчикам расширений для этого браузера. Поскольку XUL создавался именно под нужды написания кросс-платформенного браузера, то его объектная модель и общая структура во многом схожи с аналогичными для Dynamic HTML (DHTML), а потому те, кто знаком с DHTML, смогут несколько быстрее освоить и XUL. Но "несколько" - это все-таки именно несколько. Если вы помните, когда-то достаточно давно тому назад я рассказывал в "Компьютерных вестях" об HTMLayout - библиотеке, позволяющей конструировать GUI "настольных" приложений на основе HTML. В общем-то, в основе HTMLayout и XULRunner (платформы для XUL) лежит одна и та же идея, заключающаяся в том, чтобы вынести описание интерфейса в HTML или XML-файл и освободить разработчика от его ручного кодирования или жесткого "прописывания" UI в исполняемом файле.

Понять, насколько мощной и интересной платформой является XULRunner, на которой работает XUL-интерфейс, позволит пример, расположенный по адресу www.hevanet.com/acorbin/xul/top.xul. Откройте эту ссылку и скажите честно: ожидали ли вы увидеть что-нибудь подобное в браузере? Этот пример хорош тем, что можно посмотреть и исходные тексты XUL-интерфейсов, чтобы понять, в чем именно заключается сущность XUL и как все это работает на практике.

Что ж, думаю, пока что разговор о создании расширений для Mozilla Firefox придется прервать с тем, чтобы вернуться к нему через неделю, когда вы уже вволю насладитесь демонстрацией возможностей XUL.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

okkamas_knife да какая от них польза бедному чайнику - пока вникнешь голова распухнет .....да и не встречал я что-то детального описания  процесса "от и до" полностью на русском

Как самому сделать любимый браузер еще лучше
Создание расширений к Mozilla Firefox

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

В прошлый раз мы закончили разговор на XUL'е - поговорили о том, что именно скрывается за данной аббревиатурой и какое отношение она имеет к созданию расширений для Mozilla Firefox. И сейчас будем заниматься XUL'ом, так сказать, с практической, а не с теоретической стороны. Собственно, именно в этом занятии и состоит едва ли не самая важная часть всего процесса создания расширения для Mozilla Firefox.

XUL-слои

Поскольку записывать все сведения об интерфейсе браузера в одном XUL-файле, скажем так, не слишком удобно (да и, говоря откровенно, вряд ли бы мы с вами тогда вообще говорили о каких бы то ни было расширениях для Firefox'а). Поэтому в браузере используется несколько иной подход - интерфейс представлен в виде так называемых XUL-слоев, разнесенных по разным файлам. Это как раз и обеспечивает ту гибкость и расширяемость, которые сделали Firefox знаменитым.

Как выглядит типичный XUL-слой, можно увидеть в листинге к данной статье. В целом, думаю, данный документ не вызовет много вопросов, однако после того, как вы ознакомитесь с ним, я дам некоторые пояснения.

<?xml version="1.0"?>
<overlay id="sample"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<statusbar id="status-bar">
<statusbarpanel id="my-panel" label="Hello, World" />
</statusbar>
</overlay>

С первой строчкой, думаю, все совершенно понятно - она стандартна для всех XML-документов, и XUL-файлы, как вы сами можете убедиться, также не являются исключением из их числа. Корневой тег, overlay, дает возможность браузеру "узнать" в данном XML-файле XUL-документ. Кстати, обратите внимание на то, как именно записан URL в строке за overlay'ем. Как известно, разработчики Mozilla Firefox - те ещё шутники. Название же XUL по-английски должно произноситься примерно как "зуул" (zuul). Этот URL отсылает нас к известной комедии "Охотники за привидениями", где встречается одноименный персонаж. Фраза "There is no Dana, only Zuul" из фильма, закодированная в этом URL'е (в котором, кстати говоря, можно также увидеть ещё две отсылки к тому же фильму - "ключника" и "привратника", т.е. keymaster и gatekeeper), стала основой для девиза команды разработчиков, работающих над XUL: "There is no data, there is only XUL".

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

Тег statusbar обозначает "точку соединения" нового виджета с уже имеющимся интерфейсом. В данном случае такой точкой, как видите, является панель состояния браузера (status bar). То, что заключено внутрь данного тега - и есть, собственно говоря, виджет, который мы добавляем на нашу "точку соединения". В данном случае таким виджетом является дополнительная панель, на которой будет написано "Hello, World!".

У многих наших читателей наверняка возникнет совершенно резонный вопрос: а как же, собственно говоря, можно узнать, какие виды виджетов вообще доступны разработчику. Такой список есть на портале Mozilla для разработчиков, и располагается он по адресу https://developer.mozilla.org/en/XUL_controls. Все виджеты там расписаны более чем подробно.

Стоит, пожалуй, отдельно остановиться на вопросе добавления пунктов в контекстное меню браузера с помощью XUL-слоев, поскольку эта задача будет встречаться достаточно часто - ведь подавляющее большинство расширений для Mozilla Firefox так или иначе затрагивают контекстное меню этого браузера. Выглядит же XUL-код для добавления собственных пунктов в контекстное меню Firefox'а таким образом, как показано в листинге.

<popup id="contentAreaContextMenu">
<menuitem id="context-item1" label="Item 1" oncommand="alert('Item1');"/>
<menuitem id="context-item2" label="Item 2" oncommand="alert('Item2');"/>
</popup>

Собственно, код этого листинга достаточно прост: мы указываем, к чему "подключаемся" - в данном случае таким компонентом браузерного интерфейса является контекстное меню. В него мы добавляем два элемента, которые будут выглядеть на экране как "Item 1" и "Item 2". При нажатии на эти элементы будет выводиться окно с сообщениями, тексты которых совпадают с названиями пунктов меню. Вполне понятно, что в реальных расширениях, добавляющих собственные пункты в контекстное меню Mozilla Firefox, вместо кода, отвечающего за отображение малоинформативных сообщений, вставляют реальный рабочий код, выполняющий реальные же задачи. Впрочем, о коде сейчас ещё говорить несколько преждевременно - мы еще не до конца разобрались с XUL'ом...

Chrome URI

Каким именно образом Firefox обнаруживает элементы интерфейса, записанные в XUL-файлах? Логично было бы предположить, что для этого используются пути к файлам, в которых содержатся XUL-слои. В общем-то, так оно и есть. Только для записи таких путей в форме URI используется не привычное всем "file://", а "chrome://".

Здесь наверняка возникнет вопрос: какое отношение этот Chrome имеет к браузеру Google Chrome? В общем-то, никакого, это, можно сказать, "однофамильцы". Дело в том, что браузеры Mozilla Firefox и Google Chrome, как вам, должно быть, известно, основываются на двух разных "движках" и имеют, соответственно, достаточно рознящееся друг от друга внутреннее устройство. Что касается названия Chrome в случае с Firefox'ом, то оно исторически появилось раньше названия гугловского браузера, но теперь вместо Mozilla Chrome говорят более емкое и короткое определение - просто XUL, которое к тому же лучше отображает сущность этой технологии. В терминологии Mozilla сейчас принято следующее определение: "Chrome is the set of user interface elements of the application window that are outside of a window's content area". То есть, в Chrome включаются все те части интерфейса, которые не содержат в себе непосредственно контента web-страницы, то есть, различные панели инструментов, меню, "прогресс-бары" и т.п.

А вообще, название Chrome не такое уж редкое в мировой ИТ-индустрии. Так называется и разработанная для платформы .NET версия языка Object Pascal, и достаточно известный игровой движок, и даже серия видеокарт от S3. Так что если вдруг придется искать название для какой-нибудь своей разработки, смело называйте её "Хромом" - все поймут и не удивятся.

Но вернемся, собственно, к Chrome URI. Каким образом они вообще выглядят и используются? А вот каким: chrome://browser/content/browser.xul. Попробуйте ввести этот URI в адресной строке Firefox, и вы увидите, что именно скрывается за этим адресом. Собственно, префикс "chrome://", с которого начинается URI, нужен, по большей части, именно для того, чтобы отделять XUL-слои от web-страниц, файлов на жестком диске, папок на FTP-сервере и т.д. За этим префиксом следует название пакета, которое должно быть, по возможности, уникальным, за этим названием идет тип ресурса. Всего разработчикам доступно три различных типа ресурсов: content (сюда входят XUL, JavaScript, XBL биндинги... - собственно, то, что является формой поведения UI приложения) locale (DTD, .properties-файлы и другие вещи, которые содержат в себе строки локализации интерфейса браузера) и skin (CSS и изображения, которые составляют часть темы UI браузера). Как видите, все эти три типа ресурсов достаточно сильно отличаются друг от друга, а потому вряд ли может возникнуть такая ситуация, когда вы спутаете случайно один с другим. Что касается дальнейшей части URI, то это, собственно, путь к ресурсу - то есть, к нашему XUL-файлу. Для преобразования Chrome URI в реальный путь к файлу на диске (в том числе и находящемуся внутри какого-либо архива) браузер использует так называемый Chrome Registry (реестр Chrome). Собственно, лично нам в данном случае нужно от Chrome Registry совсем немного - а именно, чтобы туда попали URI, которые имеют непосредственное отношение к содержимому нашего расширения для браузера.

Для этой цели в Mozilla Firefox (да и в других продуктах Mozilla) существуют специальные средства - файлы, называемые Chrome Manifest'ами. Именно в них содержится информация, которая, скажем так, способствует тому, чтобы Firefox начал адекватно использовать URI вашего расширения в Chrome Registry. Но, к сожалению, поскольку объем газетной статьи не безграничен, продолжим разговор о Chrome Manifest'ах в одном из следующих номеров "Компьютерных вестей".

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Как самому сделать любимый браузер еще лучше
Создание расширений к Mozilla Firefox

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

Chrome Manifest, начало

В прошлый раз мы остановились на обсуждении Chrome Manifest - важного для каждого расширения файла. Тогда я уже рассказывал, для чего нужны эти манифесты, но сейчас, на всякий случай, напомню, что они добавляют URI нашего расширения в Chrome Registry, делая их, таким образом, доступными для браузера. Именно поэтому важно сформировать Chrome Manifest таким образом, чтобы в нем не содержалось никаких ошибок, потому что в противном случае расширение попросту не сможет правильно интегрироваться в Mozilla Firefox.

Во-первых, о названии. Называться файл должен очень и очень просто - chrome.manifest. Как видите, все логично. Во-вторых, содержание. Файл текстовый, что, собственно, объяснимо, т.к. разработчик должен писать его "руками". Как выглядит его содержимое? В целом формат Chrome Manifest достаточно сложен - вернее, имеет достаточно длинное описание, которое вряд ли целесообразно полностью приводить в данной статье, потому что мы здесь рассматриваем не все мыслимые дополнения к Mozilla Firefox, а только расширения. Поэтому в нашем случае можно ограничиться и следующей немудреной строчкой:

content sample chrome/content/

Как видите, в этой строке есть три элемента. Идущий первым по списку обозначает тип пакета Chrome. Второй есть название самого пакета. Ну, и, наконец, третий элемент - это путь к размещению файлов в пакете Chrome.

Строка, несмотря на свою простоту, содержит сразу несколько неочевидных и достаточно тонких моментов. Каких именно? Ну, во-первых, необходимым условием правильной записи является наличие слэша (/) после пути к файлам. Во-вторых, обратите внимание на регистр символов. Не случайно вся строка записана в нижнем регистре. В документации говорится о том, что записывать в нижнем регистре необходимо только название пакета, да и то для версий Firefox и Thunderbird 2.x, которые не умеют нормально работать со смешанным регистром. И, тем не менее, неспроста, надо думать, во всех примерах все строчки записываются целиком в нижнем регистре. Можно и поэкспериментировать, чтобы узнать реальные возможности использования смешанного или только верхнего регистров символов в Chrome Manifest, но лично мне кажется, что это занятие - напрасная трата времени.

Что же на самом деле записано в рассмотренной выше строке? Фактически, указывается, что файлы пакета sample (непривычно читать название пакета с маленькой буквы?) находятся в подкаталоге chrome/content/ относительно файла Chrome Manifest. Файлы со скинами и с локализациями, соответственно, должны находиться в подкаталогах chrome/skin/ и chrome/locale/.

Более подробную информацию о том, как записываются адреса пакетов и многое другое для файла Chrome Manifest, можно узнать в документе, расположенном по следующему адресу: https://developer.mozilla.org/en/Chrome_Registration. Мы же пока не прощаемся с файлом Chrome Manifest. Потому что дальше гораздо интереснее: мы будем регистрировать созданные для расширения XUL-слои.

Chrome Manifest, продолжение: регистрация XUL-слоев

В предыдущих частях серии статей о создании расширений для Mozilla Firefox мы подробно говорили о XUL и о слоях, на которые "распадается" интерфейс браузера при ближайшем рассмотрении. Слои, которые включаются в браузер путем установки расширений, должны каким-то образом регистрироваться в Mozilla Firefox, чтобы браузер их затем правильно "подхватывал" и демонстрировал на радость пользователю. Собственно говоря, для этого нужно всего лишь добавить информацию о созданных для вашего расширения XUL-слоях в создаваемый для него же файл Chrome Manifest. И сделать это очень просто.

Слои XUL добавляются в Chrome Manifest строками следующего вида:

overlay chrome://browser/content/browser.xul
chrome://sample/content/sample.xul

Как видите, и здесь строка является как бы трехкомпонентной. Но компоненты, конечно, имеют уже несколько иное значение. Первый элемент - обозначение того факта, что данная строка добавляет в интерфейс браузера новый слой. Следующий, второй по счету, это "база" для нового слоя - в данном случае этой "базой" является основное окно браузера. Третий элемент - тот XUL-файл, который планируется добавить в интерфейс данным расширением. Во время загрузки расширения содержимое sample.xul связывается с содержимым browser.xul, и пользователь видит интерфейс браузера с уже установленным в нем расширением.

Ну, хорошо, Chrome Manifest успешно записан. Что дальше? А дальше настало время несколько пристальнее взглянуть на сами расширения как таковые - из чего они вообще состоят, и что туда еще можно добавить.

Расширение как единое целое и его структура

Возможно, с этого стоило начинать разговор о создании расширений для Mozilla Firefox, но мне кажется, что уместнее посмотреть на расширение для браузера как на единое целое уже сейчас, когда мы знакомы со многими (но далеко не со всеми) частностями.

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

/install.rdf
/components/*
/components/cmdline.js
/defaults/
/defaults/preferences/*.js
/plugins/*
/chrome.manifest
/chrome/icons/default/*
/chrome/
/chrome/content/

Фактически, то, что непосредственно отвечает за работу вашего расширения, - а это XUL-файлы и различные сопутствующие им скрипты - находится в поддиректории /chrome/content/. Соответственно, в эту папку при разработке расширения их и нужно складывать. Конечно, реальные расширения, выполняющие какую-то более-менее полезную с точки зрения пользователя работу, имеют более сложную внутреннюю структуру в силу собственной архитектурной сложности. Впрочем, мы об этом еще будем говорить немного позже, возможно, в одном из следующих выпусков "Компьютерных вестей".

Тем не менее, это вовсе не означает, что вам нужно будет самостоятельно создавать все эти папки, следить за правильностью названий и потом запаковывать все это в ZIP-архив (который и является XPI-расширением). Сгенерировать "костяк" своего будущего расширения можно с использованием чрезвычайно простого и удобного онлайн-мастера под названием Firefox/Thunderbird Extension Wizard, расположенного по адресу: ted.mielczarek.org/code/mozilla/extensionwiz. В нем вы сразу создаете "болванку", в которой содержится не только иерархия папок, но и информация о названии и версии вашего расширения, сведения о поддерживаемых версиях Mozilla Firefox и Thunderbird и даже кое-какая лицензионная информация.

Конечно, если больше нравится создавать все вручную и упаковывать WinRAR'ом, то никто вам, конечно, этого не запретит. Но, на мой взгляд, разумнее быстро сгенерировать "болванку" расширения, а освободившееся за счет такой нехилой операции время потратить на изучение чего-нибудь "продвинутого" в смысле разработки расширений.

Первое тестирование расширения

Коль скоро у нас есть сгенерированное мастером или созданное своими руками расширение, в которое мы уже что-то добавили посредством новых XUL-слоев, то можно развлечься его тестовым запуском. Возникает вполне резонный вопрос: что же для этого нужно? Оказывается, не так уж и много - достаточно немного настроить Firefox, который должен "увидеть" и "подхватить" расширение.

В каталоге с профилем Firefox (он "лежит" в Documents and Settings, ну а если вы под Linux'ом, то наверняка сами без труда найдете, где у вас профиль Firefox) нужно найти подкаталог Extensions. Если его каким-то чудом не существует, нужно создать такой подкаталог заново. Далее в нем создается пустой текстовый файл с названием, в точности повторяющим идентификатор вашего расширения (sample@example.net или что-то в том же духе). После этого в данный файл нужно записать полный путь к каталогу с вашим расширением. Путь этот, обратите внимание, обязательно должен заканчиваться слэшем (или, в случае Windows, обратным слэшем) и не должен содержать у себя в конце никаких лишних пробелов, табуляций или каких-то других символов-"невидимок". Путь, который вы указываете, должен вести не к XPI-архиву, а к "распакованному" расширению.

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

На этой мажорной ноте пока что и остановимся. Мы еще не завершаем наш разговор о расширениях к Firefox, и, надеюсь, вы не успеете забыть все то, о чем мы говорили, до выхода следующего номера "Компьютерных вестей".

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Как самому сделать любимый браузер еще лучше
Создание расширений к Mozilla Firefox

Мы с вами плавно и незаметно завершаем разговор о создании расширений для второго по популярности в мире браузера Mozilla Firefox. Надеюсь, вы еще не успели окончательно забыть все то, о чем мы говорили в предыдущих статьях на эту тему?

Закончили в прошлый раз на том, каким образом можно опробовать созданное расширение "в боевых условиях", то есть, в браузере. Наверное, на этом можно было бы и завершить разговор о расширениях к Mozilla Firefox, но он тогда получился бы, скажем так, не совсем полным. Почему? Ну, во-первых, в таком виде, в каком оно есть, наше расширение отдавать пользователям ещё нельзя, его нужно "запихнуть" в XPI-пакет. Во-вторых, есть некоторые более сложные аспекты создания расширений, о которых мы с вами пока что не говорили, но которые, тем не менее, вполне заслуживают того, чтобы быть хотя бы вскользь упомянутыми в ходе нашего разговора о создании расширений к Firefox.

Упаковка расширения в XPI-пакет

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

Как я уже говорил, XPI-пакет представляет собой, по сути, обычный ZIP-архив. Сегодня это уже достаточно распространенная практика - сохранять различную информацию внутрь ZIP-файла. Именно таким образом организованы форматы документов новых версий Microsoft Office, а также некоторых других приложений, например, известной математической среды MathCAD.

Как сделать XPI-пакет из папки, в которой находится ваше расширение? Очень просто. Для этого нужно запаковать её содержимое (не саму папку, а именно то, что в ней, то есть в корневой директории архива, должно содержаться - все дерево папок и файлов, которые лежат уже в папке с расширением) любым доступным вам ZIP-архиватором, хоть WinZIP'ом, хоть тем, который встроен в Total Commander. Можно воспользоваться инструментом Extension Builder (ted.mielczarek.org/code/mozilla/extensiondev), который берет на себя внушительную часть всей черновой работы по созданию пакета расширения.

Получившийся ZIP-архив нужно переименовать таким образом, чтобы он имел расширение XPI, а при загрузке его на сервер установить MIME-тип application/x-xpinstall, чтобы браузер правильно интерпретировал назначение данного пакета.

Собственно, пожалуй, на этом "обязательная программа" разработки расширения для Firefox подходит к концу и начинается программа вольная. Не всегда то, о чем я расскажу ниже, понадобится вам при создании расширений для Firefox, но иметь это все в виду будет весьма и весьма полезно. И, возможно, даже местами интересно.

XPCOM

Когда-то давно тому назад (еще в 2006 году) я уже рассказывал читателям "Компьютерных вестей" о замечательной и очень полезной технологии XPCOM, которая может применяться для создания кросс-платформенных приложений. В свое время эту технологию разработала для своих нужд тогда еще великая и могучая корпорация Netscape, и использовалась она, конечно же, и в браузере, который разрабатывала эта корпорация. Mozilla Firefox, как известно, имеет своим дальним предком именно браузер Netscape Navigator. Поэтому нет ничего удивительного в том, что эта технология сейчас используется и в этом браузере. Используется она, кстати говоря, и в ряде других свободных программных продуктов, например, в широко известном офисном пакете OpenOffice.org. Но сейчас мы, конечно, вспоминаем её вовсе не потому, что она такая хорошая и замечательная и много где используется, а потому, что от неё есть непосредственная польза и нам, разработчикам расширений для браузера Mozilla Firefox. Подробнее об XPCOM можно почитать в уже упоминавшейся статье "Введение в XPCOM" (см. "КВ" №43 за 2006 год) или в книге, посвященной созданию XPCOM-компонентов, на сайте Mozilla (https://developer.mozilla.org/en/Creati … Components). Книга, конечно, полнее, но она на английском.

В расширениях к браузеру могут находиться XPCOM-компоненты, которые можно писать на JavaScript'е или C++. Это очень хорошая новость для тех, кто хочет создать какое-то действительно нестандартное и нетривиальное расширение, функциональность которого нельзя обеспечить средствами обычных XUL-слоев и стандартных элементов управления XUL. Но, правда, нужно приготовиться к тому, что и разработчику будет не слишком просто, потому что разработку XPCOM-компонентов для Firefox'а без опыта вряд ли можно считать легким делом. Впрочем, и пугаться не стоит - как мудро говорится в пословице, смелым сопутствует удача.

Если вдруг вы действительно соберетесь делать свой собственный XPCOM-компонент для включения его в Firefox'овское расширение и выберете для этой цели язык C++, то вам понадобится Gecko SDK, который расположен по следующему адресу: https://developer.mozilla.org/en/Gecko_SDK. Обратите внимание, что для разных версий Mozilla Firefox предлагаются разные версии Gecko SDK, и при этом вам нужно использовать ту, которая соответствует минимальной версии браузера и которую будет поддерживать разрабатываемое вами расширение. Впрочем, думаю, что особенно ударяться в максимальную совместимость не следует, потому что аудитория пользователей браузера Firefox не так инертна, как аудитория того же Internet Explorer'а, а потому все-таки обновляет свой браузер, по крайней мере, с выходом "мажорных" обновлений. Что приятно, SDK есть для всех основных платформ, под которыми сидят пользователи, то есть, Windows, Mac и Linux.

Впрочем, XPCOM - вещь для расширений не обязательная. Чего не скажешь об их отладке. К сожалению, даже чрезвычайно талантливые разработчики редко пишут код, который вообще не нуждается в отладке. Так что отладка - весьма насущный при создании расширений к Firefox вопрос.

Отладка расширений

Отладка расширений сводится, по большому счету, к отладке JavaScript'а, реализующего логику работы расширений. Можно, конечно, говорить как об отладке и о доведении до ума XUL-файлов, описывающих интерфейс расширения, но это все-таки, мне кажется, до неё немного не дотягивает. Отладка XPCOM-компонентов, если они присутствуют в вашем расширении, - вообще отдельный разговор, который сейчас лучше даже не начинать.

На тему отладки JavaScript'а для начала рекомендую посмотреть https://developer.mozilla.org/en/Debugging_JavaScript и https://developer.mozilla.org/en/Debugg … pplication.

Вам могут пригодиться для этого некоторые дополнительные инструменты. В первую очередь, наверное, DOM Inspector - https://developer.mozilla.org/en/DOM_Inspector. Он позволяет просматривать значения атрибутов, DOM-структуры и др. Вообще, надо сказать, что DOM Inspector будет полезен на всех этапах разработки расширения, в том числе и для того, чтобы увидеть структуру тех областей браузера, которые вы собираетесь расширять собственными XUL-слоями. В старых версиях Firefox этот инструмент шел в стандартном инсталляторе браузера, но сейчас его уже нужно устанавливать отдельно. Другой полезный инструмент называется Venkman, найти его можно по адресу https://developer.mozilla.org/en/Venkman. Он позволяет расставлять в JavaScript'е "брейкпоинты" (точки остановки) и выполнять, таким образом, скрипт ровно до того момента, как в нем что-то пойдет не так.

Не нужно, конечно, забывать и о "детстве" человечества - то есть, о такой простой, но эффективной технике, как "printf debugging", то есть, о банальном ведении лога или выводе сообщений о тех или иных результатах тех или иных действий скрипта на экран. Зачастую вам даже не придется делать никаких более сложных и глубоких шагов: ведь, как известно, понимание того, где скрывается проблема, - уже, как минимум, треть её решения.

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

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

Резюме

Что ж, пока что все. Вряд ли, конечно, все, кто прочитал все пять статей, кинутся сразу же создавать свое расширение, но, думаю, рассказ был для вас полезен. А те, кто действительно имеет какие-то задумки по поводу улучшения функциональности любимого браузера (которым, конечно же, всенепременно является именно Mozilla Firefox), возможно, получили толчок к реализации своих задумок. В любом случае, если у вас созрели планы по поводу собственного расширения, не стоит откладывать их в долгий ящик, потому что иначе они имеют тенденцию не реализовываться.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Как самому сделать любимый браузер еще лучше
Создание дополнений к Firefox с помощью JetPack

Казалось бы, все, что можно сказать по поводу создания дополнений к популярному браузеру со страниц газеты, уже сказано... Оказывается, все-таки сказано ещё не все. Поэтому сегодня мы говорим о JetPack - весьма интересном, с точки зрения создателя дополнений к Mozilla Firefox, инструменте.

Общие слова

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

JetPack (а именно так называется инструмент, о котором мы с вами сейчас будем вести речь) появился сравнительно недавно, около года назад. Нужно сказать, что появление JetPack действительно привело к всплеску интереса со стороны разработчиков к созданию расширений для браузера Firefox, потому что этот пакет смог предоставить программные интерфейсы (API), которые для большинства разработчиков были более привычны, нежели "классические" для продуктов Mozilla технологии, такие, как XUL, о котором мы с вами не так давно говорили. Впрочем, наверное, лучше перейти к рассказу о самом пакете JetPack.

JetPack как он есть

JetPack - это SDK для разработки расширений к программным продуктам производства Mozilla, прежде всего, к браузеру Firefox. Найти этот SDK в Сети чрезвычайно просто, достаточно зайти на его официальный сайт https://jetpack.mozillalabs.com. Там можно, само собой, обнаружить и документацию по всему пакету - к слову, достаточно полную и позволяющую действительно быстро разобраться в создании расширений с его помощью. Помимо самого SDK, для разработки расширений с использованием его наиболее актуальной версии вам понадобятся Python 2.5 (или более новый) и, на выбор, рабочая версия Firefox или Thunderbird, либо же XULRunner SDK с поддержкой Gecko 1.9.2 или новее.

Первоначально в проекте JetPack разработчикам предлагался только API, который имел следующие возможности: поддержка работы со строкой статуса, табами, управление анимацией, привязка скриптов к контенту и т.д.; поддержка подключения расширяющих API внешних библиотек (например, Twitter); поддержка библиотеки jQuery; поддержка отладки расширений с использованием Firebug. С тех пор утекло уже немало воды (согласитесь, за год можно написать достаточно много программного кода, и не только написать, но и отладить, так что в том, что сегодня JetPack уже совсем другой, чем год назад, на мой взгляд, нет совершенно ничего удивительного). Сейчас JetPack SDK включает в себя поддержку написания не только расширений для Firefox, но и "отдельно стоящих" web-приложений. Помимо, собственно, библиотек, SDK также включает ряд утилит командной строки, предназначенных для упаковки разработанного программного кода в пакеты, пригодные к распространению через Интернет. И, самое главное, в SDK есть собственная IDE для разработки расширений - пока она доступна только в предварительной тестовой версии и вряд ли может быть полноценно использована для разработки расширений, да и список возможностей IDE, говоря откровенно, не слишком поражает воображение... Но, в целом, наличие специализированной IDE в состоянии активной разработки не может не радовать.

Технологии

Что ж, общий обзор JetPack'а мы с вами вполне себе успешно сделали. Теперь можно подойти к пакету поближе и узнать, для начала, в чем, собственно говоря, состоит технология разработки расширений браузера с его использованием.

Технологически JetPack дает возможность вести разработку с использованием привычных для каждого web-разработчика (ну или, во всяком случае, для подавляющего большинства) технологий, а именно - HTML, CSS и JavaScript. Правда, технологии, используемые в JetPack'е, не сказать чтобы такие уж передовые - например, из спецификации HTML 5 не поддерживается практически ничего. Что касается версии JavaScript, то её номер - 1.8.1. В общем-то, именно в программировании на JavaScript и заключается создание расширений с использованием JetPack. В отличие от "обычных" расширений Mozilla Firefox, где все, по большому счету, основывается так или иначе на XML (потому что тот же XUL - это тоже XML), в JetPack данные записываются с помощью JSON. Выглядит это таким образом, как представлено в листинге.

{
"description": "This package adds a context-menu item.",
"author": "Me (http://me.org)",
"dependencies": ["jetpack-core"]
}

Как видите, JSON делает данные достаточно прозрачными и удобными как для чтения, так и для редактирования. Конкретно приведенный фрагмент JSON-документа - это пример "заглавного" файла для пакета с расширением package.json. Давайте теперь посмотрим на код на JavaScript'е, который как раз и реализует обещанное в JSON'е добавление пункта в контекстное меню браузера. Вы можете увидеть его в листинге.

exports.main = function(options, callbacks) {
var contextMenu = require("context-menu");
// Create a new context menu item.
var menuItem = contextMenu.Item({
  label: "Search with Google",
  // A CSS selector. Matching on this selector triggers
  // the display of our context menu.
  context: "a[href]",
  // When the context menu item is clicked,
  // perform a Googlesearch for the link text.
  onClick: function (contextObj, item) {
   var anchor = contextObj.node;
   console.log("searching for " + anchor.textContent);
   var searchUrl = "http://www.google.com/search?q=" +
    anchor.textContent;
   contextObj.window.location.href = searchUrl;
  }
});
// Add the new menu item to the application's context menu.
contextMenu.add(menuItem);
};

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

Приведенная функция на JavaScript'е - это в некотором роде аналог функции main, знакомой каждому, кто хотя бы раз что-нибудь писал на Си. Как видите, начинается наша функция с того, что мы декларируем свою "причастность" к контекстному меню браузера. Затем добавляем (хотя добавим мы на самом деле его несколько ниже) в контекстное меню новый пункт путем создания нового экземпляра соответствующего объекта, который заполняем нужными свойствами, начиная с подписи пункта "Search with Google" и заканчивая обработчиком события, происходящего при клике по этому пункту меню. Что касается собственно обработчика, то, как легко увидеть, он как раз и реализует поиск с помощью Google путем формирования URL поискового запроса, начинающегося с "http://www.google.com/search?q=", и переходу по этому URL в текущем окне браузера. Ну а в самом конце осуществляем непосредственную "состыковку" этого нашего свежеиспеченного пункта меню и контекстного меню браузера.

Конечно, можно возразить, что ничего здесь нет такого, что нельзя было бы легко реализовать и с использованием XUL'а, но не будем забывать, что этот пример из разряда "Hello, world!", а реальные расширения несколько, скажем прямо, отличаются по своей сложности от этого примера. Кроме того, не будем забывать о том, что XUL нам как бы нужно учить с нуля практически каждому, кто берется за создание расширения для Firefox, в то время как в случае с JavaScript'ом и JSON'ом многие разработчики смогут работать со знакомыми технологиями, с которыми они, образно говоря, знакомы уже всю свою сознательную жизнь. И с этим нельзя не считаться.

Подводя итоги...

...можно сказать, что JetPack'у, конечно, ещё есть куда расти. И дело не только в том, что среда разработки ещё с трудом тянет даже на звание "беты", и даже не в том, что пока что сами создатели пакета предупреждают о том, что текущая версия носит статус тестовой... Просто сама библиотека недостаточно "обкатана" на большом количестве расширений, как "классическая" технология их создания на основе XUL. Ведь на её основе создано уже огромное количество самых разных расширений, а вот на основе JetPack'а, к сожалению, пока расширений разработано не так уж и много. Впрочем, все впереди, и частично даже в наших с вами в руках. Так что не бойтесь этого пакета - может быть, как раз вы сможете сделать его намного лучше, чем он есть сейчас.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Добрый день. У меня в браузере Mozilla firefox  24 версии настроены расширения  ну типо iMacros,Multifox и так далее... Тоесть всё замечательно работает,но когда я архивирую браузер и передаю его человеку то у него браузер устанавливается без всякиз расширений.Просто чистый браузер. Есть ли вариант над решением этой беды? СПАСИБО

Всем, кто хотя бы раз сталкивался с разработкой браузерных расширений известно, что это настоящий геморрой. Проблему разработки и сборки расширений под все популярные браузеры в большинстве случаев можно решить с помощью, например, Kango framework (кто не знает, Kango позволяет собирать расширения под Chrome, Firefox, Safari и Internet Explorer используя общий JavaScript код).

Берем простенькое дополнение-переводчик: main.js - 371 строка - уровень среднего скрипта, ну немного повыше, main.xul - 10 строк. Вопросы?

А на чем писать, чтобы эти 371 строчки можно было закодить одной-двумя?

А на чем писать, чтобы эти 371 строчки можно было закодить одной-двумя?

И что? Они магическим образом сделают всё?

Писать на "голом" JS сложные алгоритмы

народ чаще всего Python юсает как надстройку над джисом

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

Можно взять и посмотреть код каких-нибудь серьёзных расширений: Tab Mix Plus, Vimperator, Adblock+.
И принять истину.

1.2. JavaScript — не простой язык

Многие рассматривают JavaScript как язык простой и доступный для использования простыми пользователями. Это не так. Используя фреймворки и готовые плагины не знакомый с js человек может легко внести динамическую составляющую в веб-станичку, однако, сам написать подобные плагины, или более сложный скрипт, для решения нетривиальной задачи не способен. Популяризации этого мифа способствует распространение статей, которые, по сути, являются инструкциями по использования того или иного скрипта, но не затрагивают его внутреннее содержимое.

не знакомый с js человек ... сам написать не способен

Чувствую что на это у меня уйдет не "пару часов погуглить" (как я вначале думал), а месяцы (и может даже годы..

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

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

Если на минутку вернуться к исходной задаче, то есть "парсить выдачу яндекса и сливать полученную инфо в локальную БД", то нужно просто взять Python + Scrapy и не морочить себе голову JS. И уж тем более XUL.

Не из вредности)) Просто не знаю ничего про js (и знать не желаю, да).

"парсить выдачу яндекса и сливать полученную инфо в локальную БД"

Эта задача никак не пересекается с написанием расширения к Fx.

Эта задача никак не пересекается с написанием расширения к Fx.

А DOM-дерево как парсить без JS?

А кроме того, есть странички с AJAX-ом. Как Вы без JS-а доберетесь до данных?

Тогда чего тут понтуетесь и высокомерно себя ведёте?

Хамло-с, видимо))

И у меня более 30 лет опыт в коддинге