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

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

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

Немного знакомился с вопросом о том, какой использовать инструмент для написания кода на javascript, да и не только для того же XUL тоже надо что-то придумывать. Мои прежние попытки найти что-то серьезное для написания кода на JavaScript не привели к тому, чтобы я нашел какой-то инструмент, который бы меня заинтересовал, сейчас я пошел ни куда-нибудь, а на форум Мозиллы, там есть вот такая тема, которая в очередной раз меня убедила в том, что сколько-нибудь качественного инструмента даже для JavaScript не существует, я уже не говорю о раработке для Mozilla.

Из того, что было мной найдено для разработки под Mozilla было несколько расширений для Firefox, где авторы пытались реализовать что-то вроде визуального дизайнера XUl, но выглядит это настолько жалко, что я недолго держал это у себя. Перечислять не буду: не помню да и ищется оно в репозитории расширений Файрфокса по запросу к примеру “XUL”, довольно легко. В общем и целом останавливаться на этом не стоит. Был еще проект xulmaker, в котором авторы что-то пытались реализовать, проект умер довольно давно, да и в его стабильности есть сомнения. Что было полезного в этом проекте, так это схема для XUL, которую они использовали. Для валидации документа схемы не существует, в силу того, что формат допускает появление любых элементов и атрибутов практически в любом месте, а этого в схеме не опишешь, поскольку схема – это набор ограничений. А вот прописать в схеме предусмотренные форматом теги и правила их использования вполне можно.

Как это часто бывает, при попытке использовать схему в Visual Studio вылезла куча ошибок и схема была недоступна из-за них. Можно, конечно, заподозрить студию в том, что с ней что-то не так и она не правильно понимает правильную схему, но на сайте Мозиллы эти ребята предлагают просмотр схемы в браузере с помощью XSLT. Открыв ссылку в Firefox, я получил сообщение об ошибке теперь уже в XSLT. Так что больше склонен думать, что ошиблись разработчики зулмейкера. Схему взялся отредактировать, некоторые ошибки в ней точно были, например множественные декларации. Отредактировал как смог, схема стала доступна и можно попытаться ее использовать. Разместил здесь.

Что касается редакторов JavaScript, то тут тоже пока не определился, что лучше использовать. Редактор Visual Studio не идеален, но все-таки у него есть положительные черты. Он не поддерживает кодфолдинга, подсветки имен идентификаторов(когда при наведении каретки на имя оно подсвечивается везде в коде), да и парные элементы тоже не подсвечиваются. но зато есть надстройки для студии, которые решают эти проблемы(хотя редактор при этом порой начинает тормозить). Рефакторинга кода для этого языка там вообще нет, мое поверхностное знакомство с редактором JavaScript из NetBeans в этом смысле порадовало гораздо больше, когда я, к примеру, захотел переименовать функцию в HTML-документе, то редактор предложил мне сделать это не только в тексте скрипта, но и в атрибутах событий HTML-элементов, что меня даже немного удивило.

Есть правда и несколько приятных вещей, в редакторе студии, которые в принципе позволяют на JavaScript писать не только небольшие сценарии для веб-страниц, но и создавать довольно увесистые проекты. В первую очередь речь конечно же об XML-документировании. Казалось бы такая мелочь не может играть серьезной роли, ан нет – еще как может.

Одной из важнейших проблем этого языка при использовании его в более-менее больших проектах, а не в сценариях веб-страницы, является его слабая типизация. Редактор кода обычно просто не знает какого типа объект, хранящийся в той или иной переменной. Из-за этого он не может сообщить об ошибке, которая может возникнуть из-за несоответствия типов и не может дать подсказку по типам, в силу того, что ему неизвестно по какому именно типу давать подсказку. Кроме того, в сколько-нибудь крупном проекте держать в памяти имена всех функций и типов, а так же сигнатуры функций и состав типов – невозможно в принципе. Поэтому постоянно приходится искать в коде то, что уже написано. Кроме того, даже если разработчик и знает о том, какая функция ему нужна, нет никакой гарантии, что  он не ошибется в ее названии, хотя бы даже в регистре какого-нибудь символа, а редактор кода эту ошибку проглотит. Как это ни странно, но всего 4 XML-элемента для документирования кода и поддержки IntelliSence решают все эти проблемы. В то же время, если сравнивать возможности Visual Studio по редактированию JavaScript, ее нельзя назвать серьезным инструментом. В NetBeans  и Eclipse все описанные возможности так же присутствуют за счет jsdoc, куда можно разместить более обширные данные, многострочные, содержащие ссылки и т. д. Вот здесь обзоры возможностей Netbeans и Eclipse. Естественно даже сравнивать не стоит. Кроме того, в том же Эклипсе можно настроить DOM-объекты, а если учесть, что придется работать с XUL-объектами, у которых свой набор членов, то тут, я думаю, это важно. Таким образом студия не тянет.

И в студии и в эклипсе есть ограничения, например как документировать поля объекта я либо не понял либо это невозможно. С акцессорами свойств проблема есть и там и там(Netbeans  пока не смотрел), то есть они вообще не поддерживаются.

Есть еще одно решение вопроса, это специальные инструменты, транслирующие код с других языков на яваскрипт. Говоря о .Net языках-источниках, наверно самым известным таким проектом является Script#. Однако мне он не очень понравился. Во-перых, там поддерживается только C# в качестве языка-источника. Во-вторых, он реализован как транслятор с C#, причем далеко не все возможности языка поддерживаются. В-третьих, он сильно ориентирован на ASP.Net и Javascript Framework от Microsoft. То, что он генерирует не хочет работать на стороне клиента само по себе, а требует этого самого фреймворка, да еще и файлов сгенерированных сервером. При желании можно все приспособить, но оно того точно не стоит.

А вот что меня на самом деле порадовало, так это jsc . Транслирует он не исходный код, а уже скомпилированную сборку, то есть ему практически безразлично, на каком языке был написан исходник(хотя в документации пишется только о поддержке C#, VB.Net и F#). Код работает на стороне клиента и может распространяться в таком виде, хотя дополнительные библиотеки, сгенерированные jsc тоже нужны. Проекты создаются самые обычные, просто после компиляции кода, запускается из командной строки исполняемый файл проекта(запуск прописан в свойствах проекта после компиляции, так что не обязательно делать это вручную). Такой подход дает возможность использовать все инструменты студии, включая средства отладки кода, всевозможные инструменты типа диаграммы классов и т. д. На бесплатную версию есть ограничение – 30 компиляций в день. Но в принципе, если не запускать программу после каждого построения проекта(например для отладки) то никаких проблем это вызвать не должно.- 30 компиляций вполне хватит.

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

Начал изучать платформу 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 лет), так что можно говорить о Зулраннере, о котором и не знает почти никто? Приложения типа Файрфокса каким-то образом собираются в отдельные сборки и весят не так много, но рядовым разработчикам видимо это не доступно, ну по крайней мере если говорить об общедоступных инструментах, которые позволили бы из такого приложения создать дистрибутивный пакет.