Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Mutibility in IEditorInput (should it or shouldn't it)
Mutibility in IEditorInput (should it or shouldn't it) [message #466864] Wed, 18 January 2006 17:47 Go to next message
Wes Gilster is currently offline Wes GilsterFriend
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 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: Mutibility in IEditorInput (should it or shouldn't it) [message #467030 is a reply to message #466926] Mon, 23 January 2006 15:43 Go to previous message
Wes Gilster is currently offline Wes GilsterFriend
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.
Previous Topic:Get a View's actual location
Next Topic:Raising SWT Events
Goto Forum:
  


Current Time: Sun May 26 21:14:44 GMT 2019

Powered by FUDForum. Page generated in 0.01692 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top