Suggestions Feature Proposal
Tor Norbye
Published Sep 21 2002
Background
This is based on
some work by Dusan Pavlica to provide assistance to users
while using the IDE. As you can see from his proposal he's
advocating a "Suggestions" view which contains suggestions
provided by various NetBeans modules.
In the below I try to nail down this feature more exactly
such that we can propose module APIs, and create the
Suggestions view.
Proposal
Modules can register Suggestions. A suggestion is something like
- "Fix Copyright Year"
- "Make a BeanInfo for this class"
- "Clean up your import section - it's messy you slob",
... etc.
Fine print: To be precise I should say the modules register
"SuggestionTypes". For example, "Fix Copyright" is a type of
suggestion. When they actually spot something to be done in your code,
e.g. "replace (c) 1999 with (c) 1999-2002", this becomes a specific
Suggestion of the copyright SuggestionType.
Suggestions are added to the Suggestions View by the modules.
(When the Suggestions view is not visible, no suggestions are
added.)
The suggestions have a context menu action, "Auto Fix...". (Better
name suggestions, please.)
When you select this action, you get a "Confirmation Dialog".
The confirmation dialog tells you exactly what performing the suggestion would do. The idea here is that you may not trust
the IDE to touch your document to update your import section,
but if you get a confirmation dialog like the following you
get a warm fuzzy feeling that you know exactly what will happen:
Clean up import section:
[x] Remove empty lines
[x] Remove unused imports
java.io, java.util.List
[x] Remove redundant imports java.io.IOException
[ ] Alphabetize the imports (but
put java.* first)
-----------------------------------------------
[x] Always ask for confirmation for this suggestion
[x] Continue to suggest import section improvements
-----------------------------------------------
[ OK ] [ Cancel ] [ Help ]
This dialog also shows a second concept: you can, on a
per suggestion basis,
- Choose to disable this suggestion (e.g. you find it useless, so
don't waste CPU cycles on it, or clutter up the view), decide
whether or not you want a confirmation dialog.
- Choose to skip the confirmation step - e.g. you trust us
to just do the right thing.
Finally, some policy should be decided about how suggestions
should be worded, so that we don't end up with a suggestion
list like this:
- Import missing class
- J2EE Suggestion Wizard
- Suggestion to fix copyright
- Class Optimizer
In other words, try to get consistantly phrased suggestions.
One final idea. I remember seeing that in Cajun, there's
a "tasks" view which provides context sensitive tasks - based
on your selection. We could do that too. When a node is selected
which has an associated suggestion cookie, its suggestion is
added to the view (and when the node is unselected the suggestion
is removed). That way, the J2EE module could for example attach
a "help suggestion" which is listed whenever you select a
deployment descriptor.
Is that a good idea?
The above issues dictate what needs to go into the public APIs
so I really hope we can reach agreement on this soon.
(One more thing should be decided: exactly which properties
a suggestion has. I think the ones shown in Dusan's UI
mockup looks about right: description, category, file/lineno/url.)
XXX for sorting furposes it's better to join file&line to one field.
Related Documents
