Home » Eclipse Projects » Eclipse Platform » Composition of Refactorings(How to compose two or more refactorings into a single undoable action?)
| Composition of Refactorings [message #1118745] |
Fri, 27 September 2013 18:43  |
 Erlend Kristiansen
Messages: 2
Registered: September 2013 |
Junior Member |
|
|
I'm working on a project for a master's thesis, and I'm trying to make composite refactorings while utilizing some of the the basic refactorings already existing in Eclipse. (Children of org.eclipse.ltk.core.refactoring.Refactoring.) Specifically I'm trying to extract a method based on a selection, and then move this method to another class. I want it to happen as an "atomic" operation, in the sense that it appears to the user as being a single action, and that it can be undone in one step.
I've bumped into for example CompositeChange, but it does not apply directly to my case, since my refactorings are interfering with each other. What is the preferred way, if there is any, to combine two or more refactorings in a way that I have described?
Is there any way of chaining the two CreateChangeOperations, and pass the result to the PerformChangeOperation?
Code examples follows:
...
ICompilationUnit cu = RefaktorHandleUtils.findType(editorProject, packageName, simpleTypeName).getCompilationUnit();
ExtractMethodRefactoring extractMethodRefactoring = makeExtractMethodRefactoring(prefix, cu);
CheckConditionsOperation checkConditionsOperation = new CheckConditionsOperation(extractMethodRefactoring, CheckConditionsOperation.ALL_CONDITIONS);
CreateChangeOperation createChangeOperation = makeCreateChangeOperation(checkConditionsOperation);
makeAndRunPerformChangeOperation(monitor, undoManager, undoName, createChangeOperation);
Refactoring moveRefactoring = makeMoveRefactoring(prefix, packageName, simpleTypeName, extractMethodRefactoring);
CheckConditionsOperation checkConditionsOperation2 = new CheckConditionsOperation(moveRefactoring, CheckConditionsOperation.ALL_CONDITIONS);
CreateChangeOperation createChangeOperation2 = makeCreateChangeOperation(checkConditionsOperation2);
makeAndRunPerformChangeOperation(monitor, undoManager, undoName, createChangeOperation2);
...
public void makeAndRunPerformChangeOperation(IProgressMonitor monitor, IUndoManager undoManager,
String undoName, CreateChangeOperation createChangeOperation) throws CoreException {
PerformChangeOperation performChangeOperation = new PerformChangeOperation(createChangeOperation);
// setUndoManager is required to put the refactoring into the history:
performChangeOperation.setUndoManager(undoManager, undoName);
performChangeOperation.run(monitor);
}
Another approach I envision, is to do refactorings in a sequence, first in a "sandbox" to check that they are behaving, and then replay
them for real afterwards. With this approach, I would also need to generate some sort of undo action, that could rewind the editing history to the point in time where the sequence began. But I run into problems already by the "sandbox". For instance, I tried to make the "cu" from the code above a working copy, and then discard the changes before moving the method, just to trigger an exception, but it doesn't seem to matter.
This topic is somewhat discussed in an old forum post, but I wonder if anyone have something to add?
Erlend Kristiansen,
University of Oslo, Norway
|
|
|
| Re: Composition of Refactorings [message #1119409 is a reply to message #1118745] |
Sat, 28 September 2013 12:17  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
You'd better ask at the jdt newsgroup
Tom
On 28.09.13 00:34, Erlend Kristiansen wrote:
> I'm working on a project for a master's thesis, and I'm trying to make
> composite refactorings while utilizing some of the the basic
> refactorings already existing in Eclipse. (Children of
> org.eclipse.ltk.core.refactoring.Refactoring.) Specifically I'm trying
> to extract a method based on a selection, and then move this method to
> another class. I want it to happen as an "atomic" operation, in the
> sense that it appears to the user as being a single action, and that it
> can be undone in one step.
>
> I've bumped into for example CompositeChange, but it does not apply
> directly to my case, since my refactorings are interfering with each
> other. What is the preferred way, if there is any, to combine two or
> more refactorings in a way that I have described?
>
> Is there any way of chaining the two CreateChangeOperations, and pass
> the result to the PerformChangeOperation?
>
> Code examples follows:
>
>
> ..
> ICompilationUnit cu = RefaktorHandleUtils.findType(editorProject,
> packageName, simpleTypeName).getCompilationUnit();
>
> ExtractMethodRefactoring extractMethodRefactoring =
> makeExtractMethodRefactoring(prefix, cu);
> CheckConditionsOperation checkConditionsOperation = new
> CheckConditionsOperation(extractMethodRefactoring,
> CheckConditionsOperation.ALL_CONDITIONS);
> CreateChangeOperation createChangeOperation =
> makeCreateChangeOperation(checkConditionsOperation);
> makeAndRunPerformChangeOperation(monitor, undoManager, undoName,
> createChangeOperation);
>
> Refactoring moveRefactoring = makeMoveRefactoring(prefix, packageName,
> simpleTypeName, extractMethodRefactoring);
> CheckConditionsOperation checkConditionsOperation2 = new
> CheckConditionsOperation(moveRefactoring,
> CheckConditionsOperation.ALL_CONDITIONS);
> CreateChangeOperation createChangeOperation2 =
> makeCreateChangeOperation(checkConditionsOperation2);
> makeAndRunPerformChangeOperation(monitor, undoManager, undoName,
> createChangeOperation2);
> ..
>
>
>
> public void makeAndRunPerformChangeOperation(IProgressMonitor monitor,
> IUndoManager undoManager,
> String undoName, CreateChangeOperation createChangeOperation)
> throws CoreException {
> PerformChangeOperation performChangeOperation = new
> PerformChangeOperation(createChangeOperation);
> // setUndoManager is required to put the refactoring into the history:
> performChangeOperation.setUndoManager(undoManager, undoName);
> performChangeOperation.run(monitor);
> }
>
>
> Another approach I envision, is to do refactorings in a sequence, first
> in a "sandbox" to check that they are behaving, and then replay
> them for real afterwards. With this approach, I would also need to
> generate some sort of undo action, that could rewind the editing history
> to the point in time where the sequence began. But I run into problems
> already by the "sandbox". For instance, I tried to make the "cu" from
> the code above a working copy, and then discard the changes before
> moving the method, just to trigger an exception, but it doesn't seem to
> matter.
>
> This topic is somewhat discussed in
> http://www.eclipse.org/forums/index.php/m/242334/, but I wonder if
> anyone have something to add?
>
> Erlend Kristiansen,
> University of Oslo, Norway
|
|
|
Goto Forum:
Current Time: Fri Apr 26 13:48:23 GMT 2024
Powered by FUDForum. Page generated in 0.03131 seconds |
] 
Search
Help
Register
Login
Home
