Difference between revisions of "Compare"

From Eclipsepedia

Jump to: navigation, search
 
 
(26 intermediate revisions by one user not shown)
Line 1: Line 1:
In the 3.3 release, we are planning on working on some of the outstanding defects that have accumulated for the Compare component. Some of the areas we plan on looking at are:
+
This page contains links related to the Eclipse Compare Framework
  
* Asynchronous loading and update of compare editors
+
*[[Compare Word Documents | Comparing Word Documents in Eclipse]]
* Improving the save life-cycling
+
*[http://www.eclipse.org/documentation/ On-line documentation]
* Improving difference and change Navigation
+
*[[Team | Team Wiki Page]]
* Use of text buffers when comparing local content
+
*[[Platform | Platform Wiki Page]]
* Upgrade to use the new Commands/Key bindings framework
+
* Swithc to using the History view for local history operations (Compare/Replace/Restore)
+
  
The following sections outline some thoughts on each of these areas.
+
[[Category:Eclipse Project]]
 
+
== Save Life-cycle ==
+
 
+
Saving properly in the Compare framework has always been a bit of a black art. The reason for this is the layered nature of the Compare framework. For a local file, the layers are:
+
 
+
# The file (instance of IFile)
+
# The ResourceNode (instance of IEditableContent)
+
# The TextMergeViewer
+
 
+
Assume you have an merge viewer open and edit the left side. A save is triggered by a Save operation or selecting another element to edit. What happens in this case is the following:
+
 
+
# save is called on ContentMergeViewer
+
# save obtains the content from the left side Document in the content merge viewer (problem: content is assumed to be a byte array).
+
# content from document is passed to the viewer content provider (instance of MergeViewerContentProvider)
+
# the content provider calls saveContent on the left typed element of the compare input if the compare input is an IEditableContent).
+
# the ResourceNode updates its buffer to contain the new content and fire a change event
+
# if you want the file to be saved, you would need to listen to that event and call commit on the ResourceDiffNode
+
 
+
- i.e. the viewer fires a dirty-changed event and the containing compare editor listens and reacts to these.
+
- A listener on the compare input could then decide to save to disk but would need to ensure that the viewer fired another dirty-changed
+
- there is a content change notifier API that can be used on a typed element to notify of content changes but this has no dirty indication
+
- there is special handling in ContentMergeViewer for firing changes for a ResourceCompareInput.MyDiffNode
+
The CompareEditorInput that contains the merge viewer keeps track of all the dirty inputs so it knows when a save of everything is required
+

Latest revision as of 12:15, 11 June 2008

This page contains links related to the Eclipse Compare Framework