вторник, 3 апреля 2012 г.

Начал изучать платформу Mozilla.

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

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

Теперь немного о том, что сразу же вызывает затруднения и, судя по всему, и в дальнейшем будет не намного проще. Упомянутый курс на Интуите по всей видимости написан довольно давно и с тех пор кое-что изменилось. В процессе чтения первой лекции у меня было желание послать все к чертям собачьим из-за того, что я нигде в Интернете не мог найти место, где можно скачать платформу Mozilla, для запуска автономных приложений. Справедливости ради следует сказать, что автор курса упомянул о том, что все написанное верно для “классического” браузера, даже версию указал и все такое, тем не менее перспектива изучать технологию, чтобы потом выяснить, что изученное уже давно не актуально и переучиваться меня не особенно вдохновляла. Поэтому я сразу взялся все делать под современную версию платформы. Так вот все мои усилия, направленные на поиск платформы таки увенчались успехом в конце концов. Тот проект, о котором писалось в курсе либо почил с миром(а нынешний – просто его форк), либо был произведен ребрендинг – не суть важно, но в настоящее время среда для запуска автономных приложений на этой платформе называется XulRunner и именно под ним работает то, о чем написано в курсе, но…

Насколько я могу судить, этот курс является наиболее подробным и фундаментальным пособием по вопросу. Из него (да и из собственного опыта) я узнал, что документация по разработке под Мозиллу составлена мягко говоря не самым лучшим образом. Отдельные топики на официальном сайте никак не систематизированы и в одну кучу свалено все, что актуально для разных версий и приходится долго рыться для того, чтобы понять, что подходит для текущей версии, а что уже устарело и если устарело, то найти более новую информацию – задача не такая уж и простая.

В данный момент мне просто выносит мозг chrome-адресация. Идея собственной внутренней адресации весьма недурна. Взять к примеру локализацию приложений все ресурсы локализации находятся в отдельном каталоге, в этом каталоге для каждого языка есть собственный подкаталог, chrome-адресация устроена таким образом, что для всех этих подкаталогов будет использоваться один и тот же адрес, только выбираться конкретная локализация будет в зависимости от настроек системы. Аналогичная ситуация с темами, скинами и прочим. Все это позволяет в тех местах приложения, которые зависят от конкретной локализации или темы указывать один адрес и больше ни о чем не думать. Проблема в том, что все такие адреса надо регистрировать. В курсе говорится, что для этого надо вносить изменения в файл install-chrome.txt, и создавать файл content.rdf. Я довольно долго искал, где находится файл install-chrome.txt, и в лекции(думая, что что-то пропустил) и в сети и в каталогах Файрфокса и Зулраннера, но все было тщетно. Поиск по сети тоже ничего не дал. Потом, изрядно помучившись, до меня начало доходить, что эти данные надо вносить в манифест приложения. Изучив документацию, я попробовал все, но пока ничего не получилось. Поиски информации по этому вопросу в сети тоже пока не принесли результата. Полагаю, в дальнейшем я найду ответ и на этот и на другие вопросы, но все эти поиски настолько утомляют, что довольно велика вероятность того, что все это надоест раньше, чем будет достигнут какой-то результат.

В целом, что порадовало, это то, что для освоения базовых возможностей платформы серьезных усилий не потребуется, если знаком (хотя бы на элементарном уровне) с клиентскими технологиями веб-разработки, такими как: HTML, XML, CSS и JavaScript. Основная масса того, что понадобится для разработки под Мозиллу вполне вписывается в эти технологии.

Весь пользовательский интерфейс описывается на языке XUL, являющемся словарем XML. Есть правда и здесь своя ложка дегтя: дело в том, что сколько-нибудь развитых инструментов для работы с XUL я не нашел, а использовать обычный XML – редактор видимо будет затруднительно, в силу того, что XUL не вписывается ни в какую схему. У него есть собственный набор элементов и атрибутов, но, практически в любом месте документа, можно добавлять собственные элементы. То есть описать документ в схеме вряд ли возможно, а стало быть codecomplition существующих XML редакторов может оказаться полезным только в том случае, если для них сознательно ограничить возможности языка и сразу заложить либо фиксированный набор элементов, либо ввести самостоятельно ограничивающие правила для их появления в документе. Вроде есть в сети такие схемы, но я их еще пробовал использовать.

Способ отображения элементов зависит о стилей CSS, что тоже довольно приятно, в силу того, что не придется изучать что-то новое. О том, какая версия CSS поддерживается в настоящее время говорить трудно, поскольку курс малость устарел и как дела обстоят сейчас я не знаю, но по-моему неплохо. Поддерживаются не все возможности CSS, но в то же время есть масса собственных свойств и значений для стилей. Многие из них достаточно интересны, но как обстоят дела с документацией этих возможностей я не в курсе. Искал документацию по стилям Мозиллы, вводя в поле запроса Гугла специфические для Мозиллы названия свойств, но тот ничего не находил. Видимо придется довольствоваться тем, что есть в курсе.

Логика приложения полностью описывается на JavaScript. Опять-таки проблем это не вызывает. Возможности языка можно расширить компонентами XPCOM, что позволяет выполнить практически все, что может понадобиться. Работать с этим компонентами непросто(по крайней мере новичку), но есть всякие вспомогательные JavaScript-библиотеки, которые облегчают эту задачу(хотя можно обойтись и без них). Примером такой библиотеки может служить jsLib.

Для вводимых пользователем новых элементов XUL существует стиль и поведение по умолчанию, но можно определить и свои собственные. Как минимум это CSS-описание, но так же можно создать документ в формате XBL, который позволяет создавать логику поведения элементов. Я пока еще не дошел до подробного изучения этой темы, но, насколько я понял, это что-то вроде HTML-компонентов (HTC) от Майкрософт. Там эту технологию до ума не довели и забросили, а здесь это работает. Сам формат XBL основан на XML, что тоже приятно.

Данные описываются в RDF/XML, что опять-таки радует. Строки локализации и не только хранятся в DTD-файлах в виде объектов подстановки (ENTITY). Для изменяемых строк(к примеру настроек приложения) тоже есть довольно простой формат файла(что-то вроде ini-файлов, но с расширением .properties).

XulRunner существует для разных платформ и приложения, написанные под него будут работать везде, что, конечно же, не может не радовать. А вот запускать приложения не очень удобно. Фактически никакого exe-файла нет. Есть сам XulRunner и запускать надо именно его, а в качестве аргумента ему следует передавать адрес файла application.ini приложения. Естественно запускать программу каждый раз таким образом не очень удобно, поэтому я вышел из положения следующим образом: создаю переменную среды с именем xulrunner и значением в виде адреса его исполняемого файла xulrunner.exe в кавычках. Теперь, для создания ярлыка мне надо создать его для файла application.ini после чего отредактировать свойства ярлыка так, чтобы адрес выглядел следующим образом
%xulrunner% “c:/appdir/application.ini”
Ну и дальше все как обычно.

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

Развертывание автономных приложений – тоже проблема. Дело в том, что для их работы нужен XulRunner, таким образом, для того, чтобы приложение работало на другой машине его там придется установить. С одной стороны ничего сложного в этом нет, особенно если учесть, что установка сводится к распаковке архива в любой каталог. С другой – не многим хочется устанавливать 60 МБ Зулраннера для того, чтобы работало небольшое приложение под ним. Если с установкой Явы и Дотнета у некоторых проблемы(даже не смотря на то, что последней версии системы Windows, в которую Дотнет не входит уже около 10 лет), так что можно говорить о Зулраннере, о котором и не знает почти никто? Приложения типа Файрфокса каким-то образом собираются в отдельные сборки и весят не так много, но рядовым разработчикам видимо это не доступно, ну по крайней мере если говорить об общедоступных инструментах, которые позволили бы из такого приложения создать дистрибутивный пакет.

Комментариев нет :

Отправить комментарий