¿Cómo un EditorPart sucio prohíbe a Eclipse renombrar su recurso?

Question

Digamos que he definido mi propio TextEditorX extends TextEditor. En el escenario típico en Eclipse RCP (plugins estándar, banco de trabajo con el Explorador de proyectos/Navigator) el comportamiento cuando alguien trata de cambiar el nombre (a través de Explorador de proyectos o Navigator) un archivo que algún editor ha abierto es:

• Si el editor no es dirty, se permite el cambio de nombre. Luego se llamará a editor.setInput(), con el nuevo nombre de archivo como argumento.

• Si es dirty, se emite un error ("Cambiar el nombre de recurso": "se produjo un error fatal mientras se realiza la refactorización" "se han encontrado problemas: doc.txt es no salvo").

Mis preguntas:

• ¿En qué nivel se define este comportamiento? Supongo que el paquete org.eclipse.ltk.ui.refactoring.resource está involucrado ... Pero, supongamos, por ejemplo, que quiero rechazar el cambio de nombre incluso cuando el editor no está sucio: ¿podría este comportamiento ser determinado por algún método en el editor (o el proveedor del documento), o ¿Debo codificar/extender algunos RenameParticipant?

• ¿Cómo sabe el renombrador que el recurso doc.txt está abierto por esa instancia del editor? ¿Simplemente verifica todos los editores abiertos y pregunta a cada uno por su editorInput, o están involucrados documentProviders? Específicamente, supongamos que tengo un editor en particular que, además del archivo "principal", depende de otros recursos (una entrada de varios archivos), y quiere que el renombrador se lo pregunte antes de cambiar el nombre de cualquiera de sus entradas. ¿Cómo te acercarías a este escenario?

Answer 1

No existe un motivo teórico para que Eclipse evite cambiar el nombre de un archivo modificado. Por un lado, el editor podría registrar un ResourceChangeListener con el espacio de trabajo, y simplemente actualizar su IEditorInput en respuesta a una notificación MOVE. No estoy seguro de si esa es una buena respuesta, pero tal vez un buen enfoque para seguir.