Jump to: navigation, search


Revision as of 11:10, 19 June 2007 by Michael Valenta.ca.ibm.com (Talk | contribs) (Save Life-cycle)

This page captures some of the enhancements that were made to the Compare framework starting in the 3.3 release and continuing into 3.4.

Support for File Buffers

Eclipse has support for file buffers which are used to allow multiple editors to share the same document. When editors share the same document, changes made in one editor are reflected in the other. The following changes were made in 3.3 to support the use of file buffers in Compare editors:

  1. The ISharedDocumentAdapter interface was defined as API. The interface provides an extension to an ITypedElement that viewers can use to access a shared document (i.e. synchronized file buffer) for a types element.
  2. TextMergeViewer has been modified to make use of a shared document if a typed element being edited supplies one and the TextMergeViewer or it's subclass support it. In order to support shared documents, the subclass must use the default content provider and must provide a document partitioning if it makes use of a document document partitioner. In other words, the subclass must indicate the type of the partitioner since the default type cannot be sed for shared documents.
  3. StructureDiffViewer has been updated to support shared documents and an IStructureCreator2 interface has been defined along with a StructureCreator abstract class that provides a default implementation that manages shared documents for an element. Like TextMergeViewer, subclasses of StructureCreator must provide a document partitioning if they provide a document partitioner.
  4. The structure creator must also adapt the result returned from createStructure to a shared document adapter that wraps the adapter of the input. Ths is require to allow the viewers to detect document changes. It can use the SharedDocumentAdapterWrapper to do this and must make sure it returns the proper codument key for the original input (see bug 162561 for a request to simplify this).

Asynchronous Loading

In 3.3, changes were made to the CompareEditorInput to support asynchronous loading. Subclasses that override canRunAsJob to return true will be initialized in the background when the input is shown in an editor. The ICompareContainer interface was also introduced to allow asynchronous operations to be launched at subsequent time in the compare editor life cycle.

However, in 3.3, too much processing was put in the background. The IDocument implementation provided by Platform/Text needs to be called from the UI thread but there are some places where methods are called from a background thread. These issues will be addressed in either 3.3.1 or 3.4.

Save Life-cycle

Prior to 3.3, saving properly in the Compare framework was always a bit of a black art. See bug 125538 for a description of how this used to work. In 3.3, the SaveableCompareEditorInput was introduced and it provides the following:

  1. provides a static method createFileElement for creating a type element that represents a file.
  2. supports the use of shared documents (i.e. file buffers).
  3. supports the workbench Saveables API.
  4. auto-closes when changes are resolved.
  5. initializes asynchronously.

This class only supports the use of a single Saveable (e.g. a single file) and therefore only allows one side of the comparison to be editable. In 3.4, we would like to generalize the class (or provide another generalized class) that can support a Saveable on both the left and right sides (i.e. comparison of two local files).