Bug 280064 - [ltk] support mandatory Changes
Summary: [ltk] support mandatory Changes
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.5   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 259092
Blocks:
  Show dependency tree
 
Reported: 2009-06-12 07:56 EDT by Tom Hofmann CLA
Modified: 2009-06-17 08:54 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Hofmann CLA 2009-06-12 07:56:03 EDT
Eclipse 3.5

org.eclipse.ltk.core.refactoring.Change should support "mandatory" semantics, meaning that a mandatory change cannot be disabled by the user.

Rationale: Change is the smallest unit of modification in the refactoring framework. Often it is also used to present the structure of the refactoring to the user on the preview page. In our case, we would like to show the structure of the changes, but the entire change tree (or a certain subset of the change nodes) are mandatory, i.e. may not be disabled by the user.

It would of course be possible to prevent the user from continuing the refactoring once the mandatory changes are disabled. However, it would be much nicer to not show those changes as optional.

Since the preview page of RefactoringWizard is hard-wired, it is not possible to just replace that page.

Selectively leaving out the checkboxes for tree elements may be hard using CheckboxTreeViewer. Alternatively, the entire change tree could be marked as mandatory and a normal TreeViewer used?
Comment 1 Markus Keller CLA 2009-06-12 09:33:23 EDT
Bug 259092 and bug 203943 request API to disable (i.e. "lock") individual check boxes. We should first see whether we can go that way. If we can't, we can add a global option to remove the checkboxes from the tree.

> It would of course be possible to prevent the user from continuing the
> refactoring once the mandatory changes are disabled.

Rather than disabling the refactoring, you could also just enable the mandatory changes silently. I think you could already write a subclass of CompositeChange, mark it as synthetic in the constructor, and extend isValid(..) to enable all necessary changes again.