This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Many users are confused by how the current move/rename of files works. When they want to move classes between packages or rename them, they usually use drag&drop/cut&paste/in-place rename in explorer. These actions currently do just the file manipulation, which then triggers the refactoring. After the refactoring is cancelled, the file operation is not reverted, since from the implementation point of view these are separate operations. However this is not clear to users - they expect the file operation to be reverted too. Possible solutions: 1) Replace the file operations with real refactorings (i.e. the d&d or cut&paste will directly invoke the refactoring) - we need to find out and document (e.g. in this issue) whether this is implementable and what would need to be done to implement it or make it implementable and what are the drawbacks (so that we will have a record regarding why we decided to implement a particular solution) 2) Leave it as is, change the UI to make it more intuitive to users (provide a message box (that clearly separates the file move operation and refactoring) asking if users want to refactor after they moved the files) 3) Explicitly revert the file operation when the refactoring is cancelled.
*** Issue 45698 has been marked as a duplicate of this issue. ***
Personally, proposal 1 is the best solution. What's happens now when I am using the Refactoring menu to Move a Class: 1. Refactoring | Move Class 2. Refactoring module asks where Class must be moved 3. User introduce another package 4. Refactoring module modify all impacted files 5. Finally Refactoring module move the file to the target directory. When I do the same operation with drag and drop of file: 1. User drag a class 2. User drop the class in another folder 3. System do the move of the file 4. Refactoring is called 5. User accept operation 6. Refactoring modify all impacted files 7. Refactoring don't move the file, because it's already done So, if you drop operation 3, everything will occurs as expected and user will be happy and undo will work as expected.
Vincent, I agree, however it is not easy to implement since the d&d and cut&paste operations are provided by the IDE core. We need to find a way how to override them, which we haven't yet. Also there is a possibility that the user will really want to just move the file (and not to perform the refactoring). For this reasons we may keep the current solution for promoD and try to make it better for future promotions.
Dusane, what is your opinion? Is there any spec. covering this? Regarding possible solution 1) "replace the file operations with real refactorings": It means, that user loose possibility to rename or move java files without doing refactoring. Is that really what we want?
Reassigning to Dusan. BTW, Honzo, are there any technical problems connected to option 1)? I.e. if Dusan decides to go that way, is it realistic from the technical point of view for promoD?
Yes. Technical problem is not with rename class, or with move class. We can probably utilize JavaDataObject.handleMove(), JavaDataObject.handleRename() etc. Problem is with Move Classes (multiple classes): we cannot detect (from JavaDataObject.handleMove()) that mutliple classes are being moved.
Honza: Could you think of any workaround for moving multiple classes (catch it higher than in handleMove? e.g. hook into the d'n'd/cut&paste operation?)
I don't have any idea. Maybe Honza Pokorsky - our Node guru :) - has some thoughts. Honzo P.?
I have suggested to improve current dialog to be more informative. Try to use description defined in spec: http://ui.netbeans.org/docs/hi/javamdr/refactoring_design.html I would like to know more about those "Users that are confused by how the current move/rename of files works". Could you send to me their emails or notes about this problem please ?
Move class implemented according to ui spec: Checking in src/org/netbeans/modules/refactoring/ui/Bundle.properties; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.23; previous revision: 1.22 done Checking in src/org/netbeans/modules/refactoring/ui/MoveClassAction.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassAction.java,v <-- MoveClassAction.java new revision: 1.5; previous revision: 1.4 done Checking in src/org/netbeans/modules/refactoring/ui/MoveClassPanel.form; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassPanel.form,v <-- MoveClassPanel.form new revision: 1.4; previous revision: 1.3 done Checking in src/org/netbeans/modules/refactoring/ui/MoveClassPanel.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassPanel.java,v <-- MoveClassPanel.java new revision: 1.9; previous revision: 1.8 done Checking in src/org/netbeans/modules/refactoring/ui/MoveClassUI.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassUI.java,v <-- MoveClassUI.java new revision: 1.10; previous revision: 1.9 done Checking in src/org/netbeans/modules/refactoring/ui/MoveClassesUI.java; /cvs/refactoring/src/org/netbeans/modules/refactoring/ui/MoveClassesUI.java,v <-- MoveClassesUI.java new revision: 1.10; previous revision: 1.9 done > Could you send to me their emails or notes about this problem please ? Try vbrabant@netbeans.org or mgrummich@netbeans.org
verified in 4.2 (200507181000)