Реализация игры на JAVA

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

Следующий пример определяет стандартный текстовый  редактор Eclipse (обратите внимание на то, что задано расширение файлов, с которыми работает этот редактор - txt).

Как происходит открытие файла для редактирования? Workbench ищет в списке всех расширений org.eclipse.ui.editors те редакторы, которые способны открыть файл с данным расширением (задается атрибутом extensions). Если обнаружено более одного подходящего редактора, пользователь может выбрать, какой из доступных редакторов он хочет использовать в данном случае. Существует соглашение о том, что все редакторы Eclipse обязаны реализовать интерфейс org.eclipse.ui.IEditorPart, поэтому Workbench создает объект класса, указанного в атрибуте class расширения, и приводит его к известному ему IEditorPart. В дальнейшем управление жизненным циклом редактора осуществляется только через этот интерфейс.

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

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

Типичное  функционирование механизма расширений пояснит рисунок 4.

Клиенты точки  расширения P (они не обязательно  должны находится в плагине A, объявляющем  точку расширения) могут получить список обнаруженных расширений P (в  этом примере – единственное расширение в плагине B), создать их экземпляры и работать с ними через общий интерфейс I, объявленный в том же плагине, что и точка расширения.

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

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

При помощи описанного механизма расширений может быть расширена практически вся функциональность Eclipse – перспективы, редакторы, виды, страницы настроек, инкрементальные билдеры. Предположим, что перед вами стоит задача создания инструментария для поддержки Web-сайта. Вы можете создать новый вид проекта “Web project”, редактор html, средства синхронизации с web-серверами, и разместить все новые элементы интерфейса в отдельной перспективе.

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

Пример: создание инкрементального билдера

Эффективность работы в Eclipse велика не только благодаря  таким возможностям, как, например, поддержка рефакторинга. Множество, казалось бы, незначительных деталей  также значительно ускоряет процесс  разработки. Одна из них – вид Tasks, в котором отображается список задач (tasks). Задача – это напоминание о некоторой деятельности, после выполнения которой задача считается выполненной. JDT автоматически создает задачи для комментариев TODO и FIXME, найденных в исходном коде. Эти задачи позволяют быстро просмотреть фрагменты кода, нуждающиеся в дополнениях или исправлениях. После редактирования кода разработчик удаляет комментарий TODO или FIXME, и соответствующая задача исчезает из вида Tasks.

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

Разумеется, для поддержки локализации все  текстовые сообщения вынесены в  файлы .properties, а не закодированы в  исходных файлах Java. Поэтому задачи для непереведенных сообщений не появятся в виде Tasks автоматически, поскольку JDT создает задачи TODO только для исходных файлов java. Чтобы получить новую функциональность, нам придется создавать расширение Eclipse.

Прежде всего, при помощи стандартного мастера New Plug-in Project, создадим новый плагин под названием com.mycompany.propbuilder. Вот как выглядит дескриптор плагина plugin.xml:

Мы сразу  добавили ссылку на плагин org.eclipse.core.resources, поскольку он понадобится в дальнейшем. Кроме того, в мастере создания проекта была выбрана опция создания класса Java для плагина – PropertyBuilderPlugin. Сразу же добавим в этот класс статический метод для сообщения об ошибках, которые могут произойти во время работы плагина. Сообщения будут записаны в лог-файл eclipse/workspace/.metadata/.log.

Каким образом  можно добавить свои задачи в вид Tasks? С точки зрения реализации, каждая задача представлена отдельным маркером. Вид Tasks отображает маркеры, соответствующие  задачам, выделяя их из общего списка маркеров. Для того, чтобы маркеры можно было разделять на группы (например, отличать сообщения компилятора от задач), каждый маркер обладает своим типом (не надо путать этот тип с классами Java). Тип маркеров задач объявлен в плагине org.eclipse.core.resources и имеет идентификатор org.eclipse.core.resources.taskmarker.

Итак, для  каждого непереведенного сообщения  нам необходимо создавать новый  экземпляр маркера. Чтобы легко  отделять наши маркеры от задач, создаваемых JDT, их тип должен отличаться от org.eclipse.resources.taskmarker, но в то же время он должен указывать на то, что наши маркеры являются маркерами задач. Этого можно добиться при помощи механизма наследования – тип маркера может быть выведен из одного или нескольких базовых типов. В нашем случае, таким базовым типом является taskmarker; при этом все атрибуты, определенные в базовом типе, наследуются его потомками. Вот как выглядит объявление нового типа маркеров в файле plugin.xml:

Единственный  атрибут, который не передается при  наследовании маркеров – сохраняемость. Поскольку мы не хотим, чтобы созданные задачи пропадали при перезапуске Eclipse, атрибут persistent устанавливается явным образом.

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

Такой механизм обработки изменений в ресурсах проекта уже реализован в Eclipse –  это не что иное, как инкрементальные  билдеры. Нам остается только создать  класс Java для своего билдера (назовем его PropertyBuilder) и поместить его объявление в дескриптор плагина.

Теперь, когда  определены основные интерфейсы и алгоритмы, остается только написать класс PropertyBuilder. Как и любой инкрементальный  билдер, он должен быть выведен из класса org.eclipse.resources.InrementalProjectBuilder. Главными методами билдера являются build() и clean() – они вызываются Eclipse для обработки проекта и удаления результатов работы соответственно.