Settings API
$Revision: 1.5 $
Changes: available in
CVS
The state of the settings in NetBeans 3.5 was analysed and summarized
in
Settings
in NetBeans 3.5 document. This document addresses most of the
discovered issues and proposes several changes. The individual changes
will be in detail covered in separate proposals.
Provide single API library for unified access to settings, both to
primitive data types and instance settings. This API will replace
current need to use Filesystems and Datasystems directly for accessing
settings. The support for primitive data types will help most of
the modules to save their settings (e.g. preferences) directly in human
readable format without the need of Java Serialization.
The Registry API will also allow reverting of the customizations to the default state.
In long term this API will allow us deprecate access to settings
through the SystemFilesystem at all and evolve
current backend storage (ie. multi filesystem) to something what can be better validated.
Although the Registry API will support storage of primitive types the
object persistence must be still supported and in some scenarios be even
preferred. Convertors API from functionality point of view is subset of
the current
core/settings
module. The difference from core/settings is that:
- implementation does not uses Datasystems
- it has simplified registration
- it simplifies existing Properties convertor and encourages its
usage
- optionally provides some other convertors for general usage
- the auto saving scenario has to be rethought (it is a bit in
conflict with Registry API - must the looked-up object be bound into
registry or will it be saved automatically without the need to rebind it?)
The resulting Convertor API will have straightforward purpose:
convert file to object and convert object to file. It will be directly
used by the implementation of Registry API to convert binded objects
into persistent form and recreate instances from this persistent form.
3. Misc other helper APIs
Several other helper APIs were identified which are needed to smoothly
migrate from Datasystems usage to Registry API. Example of these APIs are
Menu bar based on top of the Registry content; similarly the Toolbar;
etc.
4. OptionsDialog API
There is missing infrastructure allowing modules to provide their own
UI which would be shown in the Options dialog instead of current
property sheet. Also the Options dialog will support standard
OK/Cancel buttons, reset to default values, etc.
