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

1 Introduction

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.

2 Options Tree

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.

3 Commit on OK

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.

4 Rollback on Cancel

Rollback on Cancel would be done by deleting of all writings from temporary layer.

Project Features

About this Project

ui was started in November 2009, is owned by Jiří Kovalský, and has 44 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close