On 11/3/11 7:59 PM, Peter Klügl wrote:
Hi,
Am 03.11.2011 18:36, schrieb Jörn Kottmann:
+1 for the changes in DefaultCasDocumentProvider, it is just a small
nice change
to refactor the existing listener.
I am a little confused about the change you did to the ICasDocument and
its listener. Shouldn't the document change be announced by the editor
itself?
Yes, this was my first solution, but I removed it because of many
smaller reasons. See below.
Otherwise a client, needs to swap its listener when a document
changed, and it is also
not the place I would look for a document changed event.
Doesn't the client needs to do that anyway? I think there is no ways
to keep the document object. So we get a new object, the listeners
need to be removed and added to the new object. Therefore, when the
method is called the old and the new document need to be available and
I prefer to provide them both in the interface instead of calling
editor.getDocument() or something.
Did I miss here something?
No, I might be handy to provide the old and the new document, but
usually you call setInput on
a JFace viewer which then still knows the old input element and calls
inputChanged on the content
provider for you, so no need to do this manually.
I suggest that we add a new listener which can be registered on the
ICasEditor
to announce ICasDocument swaps, what do you think?
It's fine for me and not much work. I removed the code again, because
the naming wasn't intuitive but misleading. CasDocumentListener sounds
like stuff the concerns also its changes. There is for example also
the viewChanged method and that's for me also something like a cas
change. I would maybe merge the cas change and the view switch event.
Then, the editor has already a listener whose name (of the field)
sounded a bit conflicting and I didn't want to rename the field. There
were also some other reasons, but I dont' remember them right now.
Overall, no important reasons, but the sum made the current solution
look a bit more sound.
If you like, then I add an additional listener structure tomorrow. I
named the interface something like ICasEditorInputListener.
I am still not sure how a view change should be handled, the current
concept is that every view
is notified so it can switch to display the view shown in the editor.
This concept also means that
CAS FS change events can only be exchanged for the current CAS view. In
the future we might need
to extend this to also support exchanging CAS change events for views
which are not "active".
I think we should maintain two different events for a Cas Document
change, and a view change of a CAS.
The event should be sent from the doSetInput method, because I would
like to use the same code
for the case that an editor is reused and provided with a new IEditorInput.
Jörn
