Bugzilla – Full Text Bug Listing
| Summary: | [refactoring] Rewrite implementations of IScriptableRefactoring.initialize(RefactoringArguments) | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, martinae |
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
Even better would be to change the initialize code to use a typed RefactoringDescriptor. > Even better would be to change the initialize code to use a typed
> RefactoringDescriptor.
We will see where the code will end up; all I want is to replace the copy-pasted "macro code" by single method invocations.
At some place the transformation to the Map takes place anyway. And imho the nicest place for it would be the descriptor. Having additional helper Methods can't be so wrong as the current code is unreadable. But a Map is a flat hierarchy. It would be good to have a distinct representation of lists instead of naming them element1, element2... That is very Win98 ini file like and a shame for the underlying xml which is meant to store tree like structures. Maybe dropping the Map concept at all would not be such a bad idea and use something more like the IMemento which is unfortunately in org.eclipse.ui. not for 3.4 This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
HEAD Implementations of IScriptableRefactoring.initialize(RefactoringArguments) are very verbose, repetitive, and error-prone. We should create some utilities that parse attributes of different types and throw an checked exception if something is not right. Thrown exceptions should be caught in the initialize(..) method and result in a fatal error status. E.g. in PromoteTempToFieldRefactoring, replace final String visibility= extended.getAttribute(ATTRIBUTE_VISIBILITY); if (visibility != null && !"".equals(visibility)) {//$NON-NLS-1$ int flag= 0; try { flag= Integer.parseInt(visibility); } catch (NumberFormatException exception) { return RefactoringStatus.createFatalErrorStatus(Messages.format(RefactoringCoreMessages.InitializableRefactoring_argument_not_exist, ATTRIBUTE_VISIBILITY)); } fVisibility= flag; } with fVisibility= ScriptableRefactoringUtil.parseInt(ATTRIBUTE_VISIBILITY, extended); or fVisibility= extended.parseInt(ATTRIBUTE_VISIBILITY);