Eclipse JDT
Release 3.0

org.eclipse.ltk.core.refactoring
Class UndoTextFileChange

java.lang.Object
  extended byorg.eclipse.ltk.core.refactoring.Change
      extended byorg.eclipse.ltk.core.refactoring.UndoTextFileChange
All Implemented Interfaces:
IAdaptable

public class UndoTextFileChange
extends Change

A change to perform the reverse change of a TextFileChange.

This class is not intended to be instantiated by clients. It is usually created by a TextFileChange object.

The class should be subclassed by clients also subclassing TextFileChange to provide a proper undo change object.

Since:
3.0

Constructor Summary
protected UndoTextFileChange(String name, IFile file, UndoEdit undo, ContentStamp stamp, int saveMode)
          Create a new undo text file change object.
 
Method Summary
protected  Change createUndoChange(UndoEdit edit, ContentStamp stampToRestore)
          Hook to create an undo change for the given undo edit.
 void dispose()
          Disposes this change. Subclasses that override this method typically unregister listeners which got registered during the call to initializeValidationState.

Subclasses may override this method.

 Object getModifiedElement()
          Returns the element modified by this Change. The method may return null if the change isn't related to an element.
 String getName()
          Returns the human readable name of this change. The name MUST not be null.
 int getSaveMode()
          Returns the change's save mode.
 void initializeValidationData(IProgressMonitor pm)
          Hook method to initialize some internal state to provide an adequate answer for the isValid method. This method gets called after a change or a whole change tree has been created.

Typically this method is implemented in one of the following ways:

  • the change hooks up a listener on some delta notification mechanism and marks itself as invalid if it receives a certain delta. Is this the case the implementor must take care of unhooking the listener in dispose.
  • the change remembers some information allowing to decide if a change object is still valid when isValid is called.

For example, a change object that manipulates the content of an IFile could either listen to resource changes and detect that the file got changed or it could remember some content stamp and compare it with the actual content stamp when isValid is called.

 RefactoringStatus isValid(IProgressMonitor pm)
          Verifies that this change object is still valid and can be executed by calling perform. If a refactoring status with a severity of RefactoringStatus.FATAL is returned then the change has to be treated as invalid and can no longer be executed. Performing such a change produces an unspecified result and will very likely throw an exception.

This method is also called by the UndoManager to decide if an undo or redo change is still valid and therefore can be executed.

 Change perform(IProgressMonitor pm)
          Performs this change. If this method is call on an invalid or disabled change object the result is unspecified. Changes should in general not respond to IProgressMonitor.isCanceled() since canceling a change tree in the middle of its execution leaves the workspace in a half changed state.
 
Methods inherited from class org.eclipse.ltk.core.refactoring.Change
getAdapter, getParent, isEnabled, setEnabled
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

UndoTextFileChange

protected UndoTextFileChange(String name,
                             IFile file,
                             UndoEdit undo,
                             ContentStamp stamp,
                             int saveMode)
Create a new undo text file change object.

Parameters:
name - the human readable name of the change
file - the file the change is working on
stamp - the content stamp to restore when the undo is executed
undo - the edit representing the undo modifications
saveMode - the save mode as specified by TextFileChange
See Also:
TextFileChange.KEEP_SAVE_STATE, TextFileChange.FORCE_SAVE, TextFileChange.LEAVE_DIRTY
Method Detail

getSaveMode

public int getSaveMode()
Returns the change's save mode.

Returns:
the change's save mode
See Also:
TextFileChange.KEEP_SAVE_STATE, TextFileChange.FORCE_SAVE, TextFileChange.LEAVE_DIRTY

getName

public String getName()
Returns the human readable name of this change. The name MUST not be null.

Specified by:
getName in class Change
Returns:
the human readable name of this change

createUndoChange

protected Change createUndoChange(UndoEdit edit,
                                  ContentStamp stampToRestore)
                           throws CoreException
Hook to create an undo change for the given undo edit. This hook gets called while performing the change to construct the corresponding undo change object.

Subclasses may override it to create a different undo change.

Parameters:
edit - the undo edit to create a undo change for
stampToRestore - the content stamp to restore when the undo edit is executed.
Returns:
the undo change
Throws:
CoreException - if an undo change can't be created

getModifiedElement

public Object getModifiedElement()
Returns the element modified by this Change. The method may return null if the change isn't related to an element.

Specified by:
getModifiedElement in class Change
Returns:
the element modified by this change

initializeValidationData

public void initializeValidationData(IProgressMonitor pm)
Hook method to initialize some internal state to provide an adequate answer for the isValid method. This method gets called after a change or a whole change tree has been created.

Typically this method is implemented in one of the following ways:

For example, a change object that manipulates the content of an IFile could either listen to resource changes and detect that the file got changed or it could remember some content stamp and compare it with the actual content stamp when isValid is called.

Specified by:
initializeValidationData in class Change
Parameters:
pm - a progress monitor

isValid

public RefactoringStatus isValid(IProgressMonitor pm)
                          throws CoreException
Verifies that this change object is still valid and can be executed by calling perform. If a refactoring status with a severity of RefactoringStatus.FATAL is returned then the change has to be treated as invalid and can no longer be executed. Performing such a change produces an unspecified result and will very likely throw an exception.

This method is also called by the UndoManager to decide if an undo or redo change is still valid and therefore can be executed.

Specified by:
isValid in class Change
Parameters:
pm - a progress monitor.
Returns:
a refactoring status describing the outcome of the validation check
Throws:
CoreException - if an error occurred during validation check. The change is to be treated as invalid if an exception occurs

perform

public Change perform(IProgressMonitor pm)
               throws CoreException
Performs this change. If this method is call on an invalid or disabled change object the result is unspecified. Changes should in general not respond to IProgressMonitor.isCanceled() since canceling a change tree in the middle of its execution leaves the workspace in a half changed state.

Specified by:
perform in class Change
Parameters:
pm - a progress monitor
Returns:
the undo change for this change object or null if no undo is provided
Throws:
CoreException - if an error occurred during change execution

dispose

public void dispose()
Disposes this change. Subclasses that override this method typically unregister listeners which got registered during the call to initializeValidationState.

Subclasses may override this method.

Overrides:
dispose in class Change

Eclipse JDT
Release 3.0

Copyright (c) IBM Corp. and others 2000, 2004. All Rights Reserved.