| Mutibility in IEditorInput (should it or shouldn't it) [message #466864] |
Wed, 18 January 2006 17:47  |
 Wes Gilster
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
As far as I can tell, the mutibility of an org.eclipse.ui.IEditorInput =
isn't really a problem until it changes in such a way that it is no long=
er =
equals() to it's prechanged state. I have found that Eclipse has, what =
it =
calls 'sanity' checks, that ensure the level of mutibility doesn't go to=
o =
far. But how far is too far?
My question is this:
When in the course of a =
org.eclipse.ui.texteditor.AbstractDocumentProvider.doSaveDoc ument(IProgr=
essMonitor,Object,IDocument, =
boolean) what happens when an IEditorInput changes so drastically that i=
t =
no longer equals() it's prechanged state? I realize that this isn't =
typical with most IEditorInputs because the equals() method depends on =
something other than the content of the IEditorInput (like for example a=
=
file path).
In essesce the question becomes this:
How/Is it possible to pass the above 'sanity' checks and still have an =
IEditiorInput's equals() method depend on the content of the IEditorInpu=
t =
and not some other factor like a filename or path?
I would think that the answer is 'OF COURSE IT'S POSSIBLE', but here is =
=
what I'm running into.
The =
org.eclipse.ui.AbstractDocumentProvider.saveDocument(IProgre ssMonitor,Ob=
ject,IDocument,boolean) =
method takes a snapshot of the ElementInfo object *before* it calls my =
doSaveDocument() method. However, inside the doSaveDocument() I do the =
=
following:
1. disconnect() the IEditorInput from the fElementInfoMap
2. change the IEditorInput in such a way that it is no longer equals() t=
o =
it's previous state
3. connect() the IEditorInput with the fElementInfoMap
4. get a handle to the new ElementInfo object that I connect()'ed in ste=
p 3
Then, when my doSaveDocument() returns back to the saveDocument(), it =
continues using the old ElementInfo it got *before* I disconnect() and =
connect()'ed my IEditorInput. Eventually, this means that call to the =
addUnchangedElementListeners() is receiving the wrong ElementInfo.
Technically, I've solved that problem by overriding the =
addUnchangedElementListeners(), but now there are different problems =
occuring. This is all begining to look like a hack to me. What should =
I =
be doing?
-- =
Thanks
Wes G.
|
|
|
| Re: Mutibility in IEditorInput (should it or shouldn't it) [message #466926 is a reply to message #466864] |
Thu, 19 January 2006 14:17  |
|
wgilster@ryko.com wrote:
> As far as I can tell, the mutibility of an org.eclipse.ui.IEditorInput
> isn't really a problem until it changes in such a way that it is no
> longer equals() to it's prechanged state. I have found that Eclipse
> has, what it calls 'sanity' checks, that ensure the level of mutibility
> doesn't go too far. But how far is too far?
>
> My question is this:
> When in the course of a
> org.eclipse.ui.texteditor.AbstractDocumentProvider.doSaveDoc ument(IProgressMonitor,Object,IDocument,
> boolean) what happens when an IEditorInput changes so drastically that
> it no longer equals() it's prechanged state? I realize that this
> isn't typical with most IEditorInputs because the equals() method
> depends on something other than the content of the IEditorInput (like
> for example a file path).
>
> In essesce the question becomes this:
> How/Is it possible to pass the above 'sanity' checks and still have an
> IEditiorInput's equals() method depend on the content of the
> IEditorInput and not some other factor like a filename or path?
IEditorInput is more like the handle to the input content (like a file
name) than the input content itself.
You would have to come up with some scheme to manage your IEditorInput
as a handle ... the content can change, but your handle remains constant.
From the java docs:
<code>IEditorInput</code> is a light weight descriptor of editor input,
like a file name but more abstract. It is not a model. It is a
description of the model source for an <code>IEditorPart</code>.
and
The actual data model should probably not be held in the input
Later,
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: Mutibility in IEditorInput (should it or shouldn't it) [message #467030 is a reply to message #466926] |
Mon, 23 January 2006 15:43 |
Wes Gilster
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
On Thu, 19 Jan 2006 09:17:29 -0500, Paul Webster <pwebster@ca.ibm.com> =
wrote:
> wgilster@ryko.com wrote:
>> As far as I can tell, the mutibility of an org.eclipse.ui.IEditorInpu=
t =
>> isn't really a problem until it changes in such a way that it is no =
>> longer equals() to it's prechanged state. I have found that Eclipse=
=
>> has, what it calls 'sanity' checks, that ensure the level of =
>> mutibility doesn't go too far. But how far is too far?
>> My question is this:
>> When in the course of a =
>> org.eclipse.ui.texteditor.AbstractDocumentProvider.doSaveDoc ument(IPr=
ogressMonitor,Object,IDocument, =
>> boolean) what happens when an IEditorInput changes so drastically tha=
t =
>> it no longer equals() it's prechanged state? I realize that this =
>> isn't typical with most IEditorInputs because the equals() method =
>> depends on something other than the content of the IEditorInput (lik=
e =
>> for example a file path).
>> In essesce the question becomes this:
>> How/Is it possible to pass the above 'sanity' checks and still have a=
n =
>> IEditiorInput's equals() method depend on the content of the =
>> IEditorInput and not some other factor like a filename or path?
>
> IEditorInput is more like the handle to the input content (like a file=
=
> name) than the input content itself.
>
> You would have to come up with some scheme to manage your IEditorInput=
=
> as a handle ... the content can change, but your handle remains consta=
nt.
>
> From the java docs:
> <code>IEditorInput</code> is a light weight descriptor of editor input=
, =
> like a file name but more abstract. It is not a model. It is a =
> description of the model source for an <code>IEditorPart</code>.
>
> and
>
> The actual data model should probably not be held in the input
>
> Later,
> PW
Thanks for the help! The Java Doc for the IEditorMatchingStrategy says =
it =
is used to deturmine which Editor is equal to another open Editor, but =
what about when an IEditorMatchingStrategy doesn't exist? In that case,=
=
is the equals() method of the IEditorInput used as a conveince to perfor=
m =
this function?
I think this explains my problem, I assumed it was the function of the =
IEditorInput to define which content is *equal* to another content. It =
=
now seems that this is only a consequence of not having an =
IEditorMatchingStrategy defined for my editor.
Sorry in advance if the java docs state this clearly, I do try to read =
them.
-- =
Thanks
Wes G.
|
|
|
Powered by
FUDForum. Page generated in 4.79386 seconds
] 
Search
Help
Register
Login
Home
