Потихоньку продолжаю осваивать курс. Поначалу это было захватывающим, но на данном этапе стало немного скучновато. Дело не в том, что курс плох, просто подача материала в нем стала напоминать скорее справочник, а не учебник. Не смотря на практические занятия сами лекции посвящены подробному рассказу о назначении каждого элемента и вариантах его использования. Все-таки для хорошего усвоения материала надо дать общие понятия и дать с ними “поиграться”, а дальше уже развивать идеи, снабжая их дополнительными подробностями, иначе книга или учебный курс превращаются в документацию или справочник, но своим первоначальным целям отвечают не вполне. Приятно, что есть такое глубокое изложение всех принципов, но, к сожалению, способ подачи материала таков, что однократного прочтения для освоения всех этих аспектов будет точно недостаточно. Видимо придется потом либо перечитать все заново, “пощупав” технологию своими руками, либо использовать этот курс в дальнейшем именно как справочник. К сожалению как справочник он видимо тоже не лишен недостатков, в силу того, что для справочника не достаточно хорошо систематизирован. Вот такое у меня сейчас впечатление. Возможно потому, что я пока не почувствовал, что усвоил пройденный материал достаточно хорошо.
Проблема с хром-адресацией (описанная в прошлой заметке) решилась довольно быстро. Действительно сейчас все адреса должны быть прописаны в манифестах, но проблема была не в этом. Дело в том, что все, что адресуется через схему 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 компиляций вполне хватит.
Буду разбираться дальше, с инструментарием все еще не определился окончательно.
Комментариев нет :
Отправить комментарий