Как грязный EditorPart запрещает Eclipse переименовывать свой ресурс? - PullRequest
7 голосов
/ 05 октября 2011

Скажите, что я определил свой TextEditorX extends TextEditor.В типичном сценарии Eclipse-RCP (стандартные плагины, рабочая среда с Project Explorer / Navigator) поведение, когда кто-то пытается переименовать (через Project Explorer или Navigator) файл, который открыл какой-либо редактор, выглядит так:

Если редактор не dirty, переименование разрешено.После этого будет вызван editor.setInput() с новым именем файла в качестве аргумента.

Если это dirty, выдается ошибка ( «Переименовать ресурс»: «Неустранимая ошибкапроизошла при выполнении рефакторинга "" Обнаружены проблемы: doc.txt не сохранен ").

Мои вопросы:

  • При которыхуровень это поведение определяется?Я предполагаю, что пакет org.eclipse.ltk.ui.refactoring.resource задействован ... Но, например, предположим, что я хочу запретить переименование, даже если редактор не загрязнен: может ли это поведение быть определено каким-либо методом в редакторе (или поставщиком документов)или я должен кодировать / расширять некоторые RenameParticipant?

  • Как переименователь узнает, что ресурс doc.txt открыт этим экземпляром редактора?Он просто проверяет все открытые редакторы и спрашивает у каждого его editorInput, или documentProviders задействован?В частности, предположим, что у меня есть конкретный редактор, который, помимо «основного» файла, зависит от других ресурсов (многофайловый ввод), и он хочет, чтобы переименователь спросил его перед переименованием любого из его вводов.Как бы вы подошли к этому сценарию?

1 Ответ

0 голосов
/ 05 апреля 2012

У Eclipse нет теоретической причины предотвращать переименование измененного файла.Например, редактор может зарегистрировать ResourceChangeListener в рабочей области и просто обновить свой IEditorInput в ответ на уведомление MOVE.Не уверен, что это хороший ответ, но, возможно, хороший подход.

...