All Packages from org.eclipse.ltk.core.* to org.eclipse.ltk.ui.*

Home >> All >> org >> eclipse >> ltk

•

Package Samples:

• org.eclipse.ltk.ui.refactoring
• org.eclipse.ltk.internal.ui.refactoring.util
• org.eclipse.ltk.internal.ui.refactoring
• org.eclipse.ltk.internal.core.refactoring
• org.eclipse.ltk.core.refactoring.participants
• org.eclipse.ltk.core.refactoring

Classes:

• Change: An abstract base implementation for object representing a generic change to the workbench. A Change object is typically created by calling Refactoring.createChange() . This class should be subclassed by clients wishing to provide new changes. Changes are best executed by using a PerformChangeOperation . If clients execute a change directly then the following life cycle has to be honored: after a single change or a tree of changes has been created, the method initializeValidationState has to be called. the method isValid can be used to determine if a change can still be applied to the workspace. ...
• Refactoring: Abstract super class for all refactorings. Refactorings are used to perform behaviour preserving work space transformations. A refactoring offers two different kind of methods: methods to check conditions to determine if the refactoring can be carried out in general and if transformation will be behavioural persevering. a method to create a Change object that represents the actual work space modifications. The life cycle of a refactoring is as follows: the refactoring gets created the refactoring is initialized with the elements to be refactored. It is up to a concrete refactoring implementation ...
• PerformChangeOperation: Operation that, when run, performs a Change object. The operation can be created in two different ways: with a given change or with a CreateChangeOperation . If created the second way the given create change operation will be used to create the actual change to perform. If the change has been performed successfully (e.g. changeExecuted() 55 returns true ) then the operation has called Change.dispose() 55 as well to clear-up internal state in the change object. If it hasn't been executed the change is still intact and the client is responsible to dispose the change object. If an undo change has ...
• TextChange: A text change is a special change object that applies a text edit tree to a document. The text change manages the text edit tree. Access to the document must be provided by concrete subclasses via the method aquireDocument 55 , commitDocument 55 , and releaseDocument 55 . A text change offers the ability to access the original content of the document as well as creating a preview of the change. The edit tree gets copied when creating any king of preview. Therefore no region updating on the original edit tree takes place when requesting a preview (for more information on region updating see class ...
• RefactoringProcessor: An abstract base class defining the protocol between a refactoring and its associated processor. The API is very similar to the one of a org.eclipse.ltk.core.refactoring.Refactoring . Implementors of this class should therefore study the interface of the refactoring class as well. A refactoring processor is responsible for: refactoring the actual element. For example if a rename Java method refactoring is executed its associated processor provides the precondition checking for renaming a method and creates the change object describing the workspace modifications. This change object contains elementary ...
• RefactoringParticipant: A refactoring participant can participate in the condition checking and change creation of a refactoring processor. If the severity of the condition checking result is RefactoringStatus.FATAL > RefactoringStatus.FATAL 55 then the whole refactoring will not be carried out. The change created from a participant MUST not conflict with any changes provided by other participants or the refactoring itself. To ensure this a participant is only allowed to manipulate resources belonging to its domain. For example a rename type participant updating launch configuration is only allowed to update launch configurations. ...
• CreateChangeOperation: Operation that, when performed, creates a Change object for a given refactoring. If created with a refactoring object directly, no precondition checking is performed. If created with a CheckConditionsOperation the requested precondition checking is performed before creating the change. If the precondition checking returns a fatal error or the status's severity exceeds a certain threshold then no change will be created. If a change has been created the operation calls Change.initializeValidationData(IProgressMonitor) 55 to initialize the change's validation data. The operation should be executed ...
• ISharableParticipant: A tagging interface to share a concrete participant instance across multiple elements to be refactored. Consider the example of moving more than one file: if a corresponding move participant is not tagged as a ISharableParticipant then a separate instance of a participant is created for every file to be moved. If the participant is marked as shared then only one instance is created and the participant is responsible to handle all files to be moved. The first element to be refactored will be added to the participant via the participant specific initialize(Object element) method. All subsequent elements ...
• IStatusContextViewer: Viewer to present the the context object of a refactoring status entry . Status context viewers are associated with a context object via the extension point org.eclipse.ltk.ui.refactoring.statusContextViewers . Implementors of this extension point must therefore implement this interface. To ensure visual consistency across all provided context viewers the widget hierarchy provided through the method createControl(Composite) 55 has to use a org.eclipse.swt.custom.ViewForm as its root widget. Clients of this interface should call createControl before calling setInput .
• RefactoringWizard: An abstract base implementation of a refactoring wizard. A refactoring wizard differs from a normal wizard in the following characteristics: only pages of type RefactoringWizardPage can be added to a refactoring wizard. Trying to add a different kind of page results in an exception. a refactoring wizard consists of 0 .. n user input pages, one error page to present the outcome of the refactoring's condition checking and one preview page to present a preview of the workspace changes. A refactoring wizard is best opened using the RefactoringWizardOpenOperation . Clients may extend this class.
• CheckConditionsContext: A context that is shared between the refactoring processor and all its associated participants during condition checking. The context manages a set of IConditionChecker objects to collect condition checks that should be perform across all participants and the processor. For example validating if a file can be changed (see IWorkspace.validateEdit(org.eclipse.core.resources.IFile[], java.lang.Object) > IWorkspace.validateEdit(org.eclipse.core.resources.IFile[], java.lang.Object) 55 should only be called once for all files modified by the processor and all participants. Note: this class is not intended ...
• IChangePreviewViewer: Viewer to present the preview for a org.eclipse.ltk.core.refactoring.Change . Viewers are associated with a change object via the extension point org.eclipse.ltk.ui.refactoring.changePreviewViewers . Implementors of this extension point must therefore implement this interface. To ensure visual consistency across all provided preview viewers the widget hierarchy provided through the method createControl(Composite) 55 has to use a org.eclipse.swt.custom.ViewForm as its root widget. Clients of this interface should call createControl before calling setInput .
• ContentStamp: A content stamp object represent the content of an IFile . A content stamp object is updated whenever the content of a file changes. In contrast to a modification stamp a content stamp is reverted to its previous value if the content of the file is reverted back by performing a corresponding undo change. Clients of the refactoring framework don't need to take care of content stamps. They are managed by the framework itself. Not all files in the workspace are annotated with a content stamp. The refactoring framework only adds content stamp to those files where necessary. Content stamp are to be ...
• TextStatusContextViewer: An abstract base implementation of a status context viewer that presents textual context information. Subclasses need to implement createSourceViewer(Composite) 55 to create the correct source viewer. They should use the method updateTitle(IAdaptable) 55 and setInput(IDocument, IRegion) 55 to set the title text and image and to populate the source viewer.
• RefactoringStatus: A RefactoringStatus object represents the outcome of a condition checking operation. It manages a list of RefactoringStatusEntry objects. Each RefactoringStatusEntry object describes one particular problem detected during condition checking. Additionally a problem severity is managed. Severities are ordered as follows: OK < INFO < WARNING < ERROR < FATAL . The status's problem severity is the maximum of the severities of all entries. If the status doesn't have any entry the status's severity is OK . Note: this class is not intended to be extended by clients.
• RefactoringWizardPage: An abstract base implementation of a refactoring wizard page. The class provides access to the refactoring wizard and to the refactoring itself. Refactoring wizard pages can only be added to a RefactoringWizard . Adding them to a normal wizard result in an exception. Note: this class is not intended to be subclassed by clients. Clients should extend UserInputWizardPage .
• DeleteProcessor: A special processor that performs delete operations. A delete processor is responsible for actually deleting the elements. Additionally it may update other resources of the same domain which are affected by the delete operation. For example, a Java delete processor could also delete additional Java elements which refer to the elements to be deleted. This class should be subclassed by clients wishing to provide a special delete processor. The main purpose of this class is type safety for the generic delete refactoring
• RefactoringStatusContext: A RefactoringStatusContext can be used to annotate a RefactoringStatusEntry with additional information typically presented in the user interface. To present a context in the user interface a corresponding context viewer can be registered via the extension point org.eclipse.ltk.ui.refactoring.statusContextViewers . This class may be subclassed by clients.
• RefactoringStatusEntry: An immutable object representing an entry in the list in RefactoringStatus . A refactoring status entry consists of a severity, a message, a problem code (represented by a tuple(plug-in identifier and code number)), a context object and a generic data pointer. The context object is used to provide context information for the problem itself. An example context is a tuple consisting of the resource that contains the problem and a corresponding line number. Note: this class is not intended to be extended by clients.
• RenameProcessor: A special processor that performs rename operations. A rename processor is responsible for actually renaming the element. Additionally it may update other resources of the same domain which are affected by the rename operation. For example, a Java method rename processor also updates all references in Java code to the method to be renamed. This class should be subclassed by clients wishing to provide a special delete processor. The main purpose of this class is type safety for the generic rename refactoring
• MoveProcessor: A special processor that performs move operations. A move processor is responsible for actually moving the elements. Additionally it may update other resources of the same domain which are affected by the move operation. For example, a Java type move processor also updates all references in Java code to the type to be moved. This class should be subclassed by clients wishing to provide a special move processor. The main purpose of this class is type safety for the generic move refactoring
• UserInputWizardPage: An abstract wizard page that is to be used to implement user input pages presented inside a refactoring wizard . User input pages are shown at the beginning of a wizard. As soon as the last input page is left the refactoring's condition checking is performed. Depending on the outcome an error page or the preview page is shown. Clients may extend this class.
• IUndoManager: An undo manager keeps track of performed changes. Use the method addUndo to add change objects to the undo stack and performUndo and performRedo to undo or redo changes. This interface is not intended to be implemented by clients. Clients should use the method RefactoringCore.getUndoManager() 55 to access the refactoring undo manager.
• Assert: Assert is useful for for embedding runtime sanity checks in code. The predicate methods all test a condition and throw some type of unchecked exception if the condition does not hold. Assertion failure exceptions, like most runtime exceptions, are thrown when something is misbehaving. Assertion failures are invariably unspecified behavior; consequently, clients should never rely on these being thrown (and certainly should not being catching them specifically).
• Assert: Assert is useful for for embedding runtime sanity checks in code. The predicate methods all test a condition and throw some type of unchecked exception if the condition does not hold. Assertion failure exceptions, like most runtime exceptions, are thrown when something is misbehaving. Assertion failures are invariably unspecified behavior; consequently, clients should never rely on these being thrown (and certainly should not being catching them specifically).

Home | Contact Us | Privacy Policy | Terms of Service