| IReusableEditor : is a file rename a "change of input"? [message #730664] |
Wed, 28 September 2011 20:08  |
 Hernan Gonzalez
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina |
Senior Member |
|
|
Is there some standard behaviour with Eclipse editors (IEditorPart) when the opened file (current editorInput) is renamed?
Specifically, I see that the interface IReusableEditor marks "editors may support changing its input", by calling setInput(). Now, it seems that the typical scenario this has in mind is when one reuses a instance of a editor to open different files.
But, say I have my editor opened with file "myfile1.txt" as input, and it's renamed (outside the editor) to "myfile2.txt": there are several possible behaviours (assuming I coded the proper listeners, so that the editor is notified) :
1. The editor tries to reopen the file at the new location (open some dialog if dirty)
2. The editor changes its input path to the new file location, but does not reload it
3. The editor does nothing, it keeps its input path (marks itself as dirty), will save to the old filename
It seems to me that options 1 and 2 implies a call to setInput(), it's not clear to me that this implies that the editor should implement IReusableEditor. It's not even clear if this should be interpreted (conceptually) as a "new input" - one could say that it's a new input source but the same input content...
Some advices, opinions, examples?
There some related old question, unaswered here
[Updated on: Wed, 28 September 2011 20:09] Report message to a moderator |
|
|
| Re: IReusableEditor : is a file rename a "change of input"? [message #734950 is a reply to message #730664] |
Mon, 10 October 2011 13:47  |
Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
On 28.09.2011 22:08, Hernan wrote:
> Is there some standard behaviour with Eclipse editors (IEditorPart)
> when the opened file (current editorInput) is renamed? Specifically, I
> see that the interface IReusableEditor marks "editors may support
> changing its input", by calling setInput(). Now, it seems that the
> typical scenario this has in mind is when one reuses a instance of a
> editor to open different files. But I have my editor opened with file
> "myfile1.txt" as input, and is renamed (outside the editor) to
> "myfile2.txt", there are several possible behaviours (assuming I know
> about listeners so that the editor is notified)
>
> 1. The editor tries to reopen the file at the new location (dialog if
> dirty)
> 2. The editor changes its input path to the new file location, but
> does not reload it
> 3. The editor does nothing, it keeps its input path (marks itself as
> dirty)
>
> It seems to me that options 1 and 2 implies a call to setInput(), it's
> not clear to me that this implies that the editor should implement
> IReusableEditor. It's not even clear if this should be interpreted
> (conceptually) as a "new input" - one could say that it's a new input
> source but the same input content...
>
> Some advices, opinions, examples?
2 is what the textual editors do. Most of the infrastructure to do this
is already there:
org.eclipse.core.internal.filebuffers.ResourceFileBuffer.handleFileMoved(IPath)
org.eclipse.ui.editors.text.TextFileDocumentProvider.FileBufferListener.underlyingFileMoved(IFileBuffer,
IPath)
org.eclipse.ui.texteditor.AbstractTextEditor.ElementStateListener.elementMoved(Object,
Object)
Dani
>
> There some related old question, unaswered
> http://www.eclipse.org/forums/index.php/mv/msg/98947/303008/#msg_303008
|
|
|
Powered by
FUDForum. Page generated in 0.02944 seconds
] 
Search
Help
Register
Login
Home
