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.
Summary: | API support for per-project hints | ||
---|---|---|---|
Product: | editor | Reporter: | Jan Lahoda <jlahoda> |
Component: | Hints & Annotations | Assignee: | apireviews <apireviews> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | API, API_REVIEW_FAST |
Priority: | P3 | ||
Version: | 7.3 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 225298 | ||
Attachments: |
Tool configuration file DTD
An example file with hints settings. |
Description
Jan Lahoda
2013-04-11 20:15:36 UTC
Created attachment 133468 [details]
Tool configuration file DTD
Created attachment 133469 [details]
An example file with hints settings.
I would like to ask for a review. Any comments are welcome. Thanks. In view of the fact that the number of settings categories can grow (we have hints, on-save actions, formatting, possibly license headers?), and so can grow the number of respective configuration files under project directory structure, it might be good to introduce a naming convention for all such files. The point is to keep orientation in e.g. nbprojects/ as simple as possible. If all configuration files were named like, e.g., cfg_?????????.xml, they could be listed together in standard file system views and many a confusion would be prevented. MK1: is the file assumed to be always shared across developers? or will we also allow dev-private settings? if so how will they interact? MK2: in case of formatting (the possible future case mentioned) how would the new format interact with the current way of sharing project formatting options? (Aux properties) (In reply to comment #4) > In view of the fact that the number of settings categories can grow (we have > hints, on-save actions, formatting, possibly license headers?), and so can grow > the number of respective configuration files under project directory structure, > it might be good to introduce a naming convention for all such files. The point > is to keep orientation in e.g. nbprojects/ as simple as possible. If all > configuration files were named like, e.g., cfg_?????????.xml, they could be > listed together in standard file system views and many a confusion would be > prevented. I'll add a note about that into arch.xml and ToolPreferences' javadoc, if that is OK&enough. MK01: So far, my idea was to read the settings from one location only, either the global settings, or the settings file, or whatever other storage the project will choose. This is mainly because usecases for settings hierarchy seem minor to me compared to UI complexity they bring. If there is a strong enough usecase to support settings hierarchy, the current API I think allows the project to do that, and the API could be extended to make that easier. MK02: The formatting part is not really finished. I expected to provide general framework to allow the change of the per-project formatting here, not to actually do that. But my idea so far was that when the settings would be converted to file (on user's request), the Preferences based settings would be stripped (or ignored). I updated the API in a few ways: -added a note about recommended config file name convention into StandardProjectSettings.createSettings' javadoc. -ToolPreferences.save is not mandatory anymore, is either saved on Preferences.flush() or automatically after a timeout (which makes the Preferences behave more similarly to other Preferences). "save()" is kept, as that makes saving UI properly easier. -added PerProjectHintsPanel.MimeType2Preferences, so that PerProjectHintsPanel can be used also without ToolPreferences (which is expected to be useful in the maven's case). Unless there are objections, I would like to integrate early next week. Any suggestions are welcome. Thanks. Seems good to me. One minor thing regarding the FileHintsPreferences.addChangeListener(). The static method probably will not work with WeakListener. |