Options Dialog Design View
Authors: Jan Rojcek,
Yarda Tulach
$Revision: 1.3 $
Document History: available in
CVS
- Abstract:
This document specifies intended implementation of Simple Options system. Implementation
should fulfill requirements and allow behavior of Simple Options system as defined in
user view
and
ui spec documents.
It doesn't provide all implementation details but it is meant to be base Simple
Options system architecture document.
- Contents:
- 1 Introduction
- 2 Options Tree
- 3 Commit on OK
- 4 Rollback on Cancel
User View and UI Spec of simplified options require additions to current
implementation. Main portion of implementation should be part of OptionsSystem
module which would be closely tied to core as open apis don't allow
to handle options system as required. To preserve modularity and extensibility
of options system some additions to module contract are also needed. Those would
be added and documented in open apis. Some portion of implementation
would be part of UIintegration module. It should contain customizers that
collect options of different modules to avoid making of dependencies between
unrelated modules.
Current structure of options presented to user in Options dialog is created
from "UI/Settings" folder. This should be preserved. Tree of options nodes
would be created from the folder and basic option nodes would be shown in
simple dialog and all option nodes in advanced dialog.
Each basic option node would provide customizer.
UI/Settings structure
Options System should know which nodes to display in simple and which in advanced
tree. "UI/Settings" structure should reflect that.
//Pending structure
Option files
As there are option categories that collect options of different modules, new file
type would be introduced and recognized by UIintegration module. Node with properties
belonging to different modules would be created from such ".option" file.
File would contain mapping to real setting properties and reflection would be used
to read actual values and store new values. The node delegate for the .option
file shall construct Node.Property objects for each property described in itself
and for properties that should delay their initialization it shall provide its
own ExPropertyEditor that will remember the chosen value and change it only after
OK is pressed. File would also contain information
about how to create a customizer.
//Pending structure
Special nodes
Some nodes would be displayed in both trees but they would be visualized
differently in both dialogs. "Collected Options Node" and "ServiceTypes Node" are
such nodes. Both nodes would be provided by UIintegration module.
Collected Options Node
This type of node have to be taken especially in Simple dialog. All its
children should be hidden in displayed tree. Its customizer would be constructed
by UIintegration module
and would contain combo box with list of children and nested cutomizer of
selected children node in combo box.
ServiceTypes Node
ServiceTypes node is folder node of ServiceType instances. Instances would be
hidden from simple tree. Its customizer would be created by UIintegration module and
would contain list of instances, list of templates, nested customizer of
selected instance and logic for creating new and destroying existing instances.
If selected instance doesn't provide cutomizer then property sheet would be
shown instead.
To achieve commit after pressing OK functionality two things have to be considered.
First, some changes (creation of new ServiceType instance) have to be performed
immediately due to architecture and this can not be changed.
Second, current options commit changes immediately. So there would be two mechanisms
providing the functionality. All settings would be written to temporary filesystem layer
when needed
and propagated to appropriate layers only after pressing OK button. Changes that cause
visual change in NetBeans (like MDI/SDI switch) would be postponed until pressing OK
button. Postponing can be achieved by ExPropertyEditor interface that would each
editor of such property implement and by ExCustomizer interface that would be implemented
by customizer of each property performing visual changes.
Temporary Filesystem Layer
//Pending
PropretyEnv additions
ExPropertyEditor interface uses ProperyEnv object for communication with Options
System. It is used for notifying about validity of edited property value.
Now PropertyEditor can be notified that it should check a value, but it is not
notified when it should apply a value. To resolve this problem two methods
should be added to PropertyEnv class.
public void addPropertyChangeListener(PropertyChangeListener pcl);
public void removePropertyChangeListener(PropertyChangeListener pcl);
PropertyEditor should listen on property "state" changes and when it changes to
PropertyEnv.STATE_VALID then it should apply new values.
ExCustomizer interface
ExCustomizer interface should provide similar validity checking and value applying
system for
customizers as ExPropertyEditor provides for property editors. So ExCustomizer
should be following interface:
public interface ExCustomizer {
public void attachEnv(PropertyEnv env);
}
PropertyPanel should be used for displaying a customizer. Wrappers wrapping Node
and its ExCustomizer by Node.Property and ExPropertyEditor should be used for that.
Rollback on Cancel would be done by deleting of all writings from temporary layer.
