Am 03.11.2011 20:59, schrieb Jörn Kottmann:
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.
Yes, but I do not use the CAS or CasDocument as input in my views for
some reasons. In some explanation views the input is set by a different
view and that input is only a subtree of some own representation. I
would provide both documents in the interface and then only call
setInput with the new one in the views that actively use the
inputChanged method.
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.
Yes, I'll implement it.
Peter
--
---------------------------------------------------------------------
Dipl.-Inf. Peter Klügl
Universität Würzburg Tel.: +49-(0)931-31-86741
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: [email protected]
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------
