Обязательные действия для адаптации механизмов и API версии 3.1

В этом разделе описаны обязательные изменения для приспособления модулей 3.0 к механизмам и API 3.1.

Поддержка отмены и повтора для платформы

В Eclipse 3.1 предусмотрена новая инфраструктура определения отменяемых действий и общей хронологии действий, отслеживающая, какие действия были выполнены, отменены и повторены. Различные схемы отмены, поставляемые в дополнительных модулях, должны были со временем быть перенесены в поддержку работы платформы, так чтобы клиенты этих схем могли бы более глубоко интегрироваться в эти платформы и делать свои отменяемые действия доступными для отмены в других панелях и редакторах модулей. Основные сведения по добавлению поддержки отмены в модули приведены в документации Отменяемые действия. Модули, которые уже определяют поддержку отмены или применяют другую схему, можно переносить в новую поддержку отмены поэтапно, как это описано ниже.

Перенос классов действий (команд) модулей в IUndoableOperation

Модули, которые уже определяют классы путем описания их отменяемых действий, должны добавлять реализацию для интерфейса IUndoableOperation в классы действий/команд. Модули могут при необходимости по-прежнему использовать старые схемы управления хронологией (стек команд), но обеспечение интерфейса для IUndoableOperation позволяет клиентам модуля применять одинаковые действия в хронологии действий платформы, а также смешивать и согласовывать отменяемые действия из разных модулей. Эта стратегия аналогична той, которая применяется в текстовых редакторах SDK для миграции в новую рабочую среду. Если прямое преобразование интерфейса невозможно, то для преобразовывать протокол IUndoableOperation в устаревшие объекты отмены можно с помощью оболочки. Эта стратегия применяется поддержкой рефакторинга Платформы/JDT. Миграция классов действий/команд в IUndoableOperation - важный шаг, так как она позволяет другим модулям использовать отменяемые операции из разных схем без необходимости переносить модуль целиком.

Миграция стеков команд с помощью IOperationHistory

Как только отменяемые действия или команды будут выражены в терминах IUndoableOperation, модули, определяющие хронологию отмены (стек команд) для отслеживания отменяемых или повторяемых действий, можно будет перенести в хронологию действий платформы путем определения IUndoContext, который представляет их хронологию отмены. Хронологии отмены, которые ранее управлялись локально, теперь можно объединять с общей хронологией действий путем определения уникального контекста отмены либо для каждого компонента, либо для каждой модели объекта, и добавления соответствующего контекста отмены в каждое действие с последующим добавлением действия в хронологию действий платформы. Хронологии отмены более глобальной области можно реализовывать путем определения уникального контекста отмены, представляющего эту область отмены, связывания этого контекста с каждым действием и последующего добавления действия в хронологию действий платформы. В документации Отменяемые действия приведены примеры создания контекстов отмены, их связывание и добавление действий в хронологию действий платформы.

Определение глобальных отменяемых действий в рабочей среде

Для того чтобы действия модулей можно было отменять из таких панелей рабочей среды, как Навигатор или Package Explorer, модули должны связать контекст отмены рабочей среды со своими действиями. В документации Отменяемые действия приведена более подробная информация об этом контексте отмены и способе его извлечения как рабочей средой, так и модулями без заголовка.

Обработчики действий отмены и повтора для платформы

Если модули не определяют инфраструктуру отмены или отменяемые операции, но им необходим доступ к хронологии отмены платформы, то следует перенастроить глобальные обработчики действий отмены и повтора на новые новые общие обработчики действий отмены и повтора. Обработчики действий должны быть связаны с контекстом отмены, который указывает отображаемую хронологию отмены и повтора. Модули могут отображать "частично локальную" хронологию отмены и повтора с помощью собственных локально заданных контекстов отмены. Для отображения хронологии отмены и повтора всей рабочей среды применяется контекст отмены рабочей среды. Полный пример приведен в документации Отменяемые действия.

Миграция действий по работе с текстом в общие обработчики событий

Миграция действий отмены и повтора в текстовом редакторе несколько отличается от простой перенастройки глобальных обработчиков действий отмены/повтора. Среда AbstractTextEditor определяет общие действия с текстом с помощью параметризованного TextOperationAction. Эти действия локально хранятся в среде и применяются для отправки различных команд в целевой объект действий с текстом в редакторе. Среде редактора для правильной работы отмены в тексте необходимо наличие правильных идентификаторов действий по работе с текстом (ITextEditorActionConstants.REDO и ITextEditorActionConstants.UNDO).

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

Для редакторов, не наследующих это поведение от AbstractTextEditor, необходимо выполнить миграцию всех существующих действий отмены и повтора, чтобы они могли применять новые обработчики. В редакторах со старыми TextOperationActions отмены и повтора все еще будет работать локальная поддержка отмены, поскольку эти действия по-прежнему поддерживают API администратор отмены JFace Text. Однако, метки действий отмены и повтора не будут совместимыми с новыми действиями отмены/повтора Eclipse SDK, отображающими имя доступного действия отмены или повтора. Для создания общих обработчиков действий отмены и повтора необходимо использовать контекст отмены, применяемый администратором отмены в программе просмотра текстов, а в редакторе для созданных действий необходимо задать соответствующий идентификатор ITextEditorActionConstants. Более подробный пример приведен с AbstractTextEditor.createUndoRedoActions() и AbstractTextEditor.getUndoContext(). Редакторы, применяющие подкласс EditorActionBarContributor для добавления инерционного ползуна, могут воспользоваться этим же способом при создании обработчиков действий отмены и повтора и указать их, когда задан активный редактор.

Расширения справки

Поиск информации

Модули, добавляющие страницы поиска в окно Поиск, должны подключать весь поиск информации к интегрированным службам поиска. Начиная с версии 3.1 весь поиск информации и стилей отделен от поиска артефактов рабочей среды. Службы поиска информации выполняются параллельно как фоновые задачи, а их результаты поиска проверяются в новой панели Справка. Дополнительная информация приведена в разделе Help Search.

Динамическая справка

Новая динамическая панель справки будет работать с существующими контекстными ID, которые статически связаны с виджетами в компонентах рабочей среды и окнах. Однако, если вы самостоятельно найдете событие справки и отобразите ее, то в динамической справке не окажется какой-либо полезной информации. Для исправления этой неполадки нужно приспособиться к новому интерфейсу IContextProvider, как это описано в документе Динамическая контекстная справка.