Home >> All >> org >> eclipse >> ltk >> core >> [ refactoring Javadoc ]

•	org.eclipse.ltk.core.refactoring.participants.* (25)

• org.eclipse.ltk.core.refactoring: Javadoc index of package org.eclipse.ltk.core.refactoring.


Package Samples:

• org.eclipse.ltk.core.refactoring.participants

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 ...
• 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 ...
• 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 ...
• 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.
• 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
• 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.
• DocumentChange: A text change that operates directly on instances of org.eclipse.jface.text.IDocument . The document change uses a simple length compare to check if it is still valid. So as long as its length hasn't changed the text edits managed have a valid range and can be applied to the document. The same applies to the undo change returned from the perform method. Note: this class is not intended to be extended by clients.
• DeleteParticipant: A participant to participate in refactorings that delete elements. A delete participant can't assume that its associated refactoring processor is a delete processor. A delete operation might be a side effect of another refactoring operation. Delete participants are registered via the extension point org.eclipse.ltk.core.refactoring.deleteParticipants . Extensions to this extension point must therefore extend this abstract class.
• RenameParticipant: A participant to participate in refactorings that rename elements. A rename participant can't assume that its associated refactoring processor is a rename processor. A rename operation might be a side effect of another refactoring operation. Rename participants are registered via the extension point org.eclipse.ltk.core.refactoring.renameParticipants . Extensions to this extension point must therefore extend this abstract class.
• UndoTextFileChange: 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.
• MoveParticipant: A participant to participate in refactorings that move elements. A move participant can't assume that its associated refactoring processor is a move processor. A move operation might be a side effect of another refactoring operation. Move participants are registered via the extension point org.eclipse.ltk.core.refactoring.moveParticipants . Extensions to this extension point must therefore extend this abstract class.
• CreateParticipant: A participant to participate in refactorings that create elements. A create participant can't assume that its associated processor is of a specific type. A create could be triggered as a side effect of another refactoring. Create participants are registered via the extension point org.eclipse.ltk.core.refactoring.createParticipants . Extensions to this extension point must therefore extend this abstract class.
• SharableParticipants: An opaque list to manage sharable participants. The list is managed by the refactoring itself. Clients typically only pass the list to the corresponding method defined in ParticipantManager Note: this class is not intended to be extended by clients.
• CheckConditionsOperation: Operation that, when run, checks the preconditions of the Refactoring passed on creation. The operation should be executed via the run method offered by IWorkspace to achieve proper delta batching. Note: this class is not intended to be extended by clients.

Home | Contact Us | Privacy Policy | Terms of Service