В этом разделе описаны обязательные изменения для приспособления модулей 3.0 к механизмам и API 3.1.
В Eclipse 3.1 предусмотрена новая инфраструктура определения отменяемых действий и общей хронологии действий, отслеживающая, какие действия были выполнены, отменены и повторены. Различные схемы отмены, поставляемые в дополнительных модулях, должны были со временем быть перенесены в поддержку работы платформы, так чтобы клиенты этих схем могли бы более глубоко интегрироваться в эти платформы и делать свои отменяемые действия доступными для отмены в других панелях и редакторах модулей. Основные сведения по добавлению поддержки отмены в модули приведены в документации Отменяемые действия. Модули, которые уже определяют поддержку отмены или применяют другую схему, можно переносить в новую поддержку отмены поэтапно, как это описано ниже.
Модули, которые уже определяют классы путем описания их отменяемых действий, должны добавлять реализацию для интерфейса IUndoableOperation в классы действий/команд. Модули могут при необходимости по-прежнему использовать старые схемы управления хронологией (стек команд), но обеспечение интерфейса для IUndoableOperation позволяет клиентам модуля применять одинаковые действия в хронологии действий платформы, а также смешивать и согласовывать отменяемые действия из разных модулей. Эта стратегия аналогична той, которая применяется в текстовых редакторах SDK для миграции в новую рабочую среду. Если прямое преобразование интерфейса невозможно, то для преобразовывать протокол IUndoableOperation в устаревшие объекты отмены можно с помощью оболочки. Эта стратегия применяется поддержкой рефакторинга Платформы/JDT. Миграция классов действий/команд в IUndoableOperation - важный шаг, так как она позволяет другим модулям использовать отменяемые операции из разных схем без необходимости переносить модуль целиком.
Как только отменяемые действия или команды будут выражены в терминах 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
, как это описано в документе Динамическая контекстная справка.