User Manual for Package

burgerraraSoftware and s/w Development

Nov 18, 2013 (3 years and 7 months ago)

48 views


1


User Manual for
ucar.util.prefs

Package


John Caron

May 17
, 2003


USER MANUAL FOR
UCAR.UTIL.PREFS

PACKAGE

................................
................................
.........

1

1.0

I
NTRODUCTION

................................
................................
................................
................................
......

1

2.0

U
SING
P
REFERENCES
E
XT

................................
................................
................................
......................

2

2.1 Initializing and saving Chained Preference Stores

................................
................................
..........

2

2.2 Working with Preferences nodes and primitive values

................................
................................
.....

3

2.3 Storing bean objects

................................
................................
................................
.........................

4

2.4 Setting the default Preferences

................................
................................
................................
.........

5

3.0

U
SER
I
NTERFACE
C
LASSES

................................
................................
................................
....................

5

3.1 Debug

................................
................................
................................
................................
...............

6

3.2 ComboBox

................................
................................
................................
................................
........

7

3.3 Field
................................
................................
................................
................................
..................

7

3.4 PrefPanel

................................
................................
................................
................................
..........

9

3.5 BeanTable, BeanTableSorted

................................
................................
................................
..........
12

BeanTable widgetReferences

................................
................................
................................
.................
13

References

................................
................................
................................
................................
.............
14

A
PPENDIX
A.

B
EAN TIMING TESTS

................................
................................
................................
..............
14

A
PPENDIX
B.

XML

FILE FORMAT

................................
................................
................................
...............
14


1.0
Introduction


JDK 1.4 adds a new package,
java.util.prefs

for storing application preferences in a central
repository. The
ucar.util.prefs

package
is an extension of
java.util.prefs

which adds
these new

features: 1)
it always uses XML files to store preference values; 2) it allows chains of “stored defaults”; 3) it allows
storage of
simple
bean

objects using reflection, and 4) it allows storage
of ar
bitrary objects using
java.beans.XMLEncoder/

XMLDecoder
, another new feature in JDK 1.4. The
ucar.util.prefs.ui

package
builds on
ucar.util.prefs

to provide convenience routines for building user preference dialogs and other user
interface components.


The

java.utils.prefs

package (aka
Preferences
) creates two trees of “preference nodes”, one for
“user preferences” and one for “system preferences”. At each node, any number of key/value pairs can be
stored. Keys are of type String, while values may be of ty
pe double, float, long, int, boolean, String, or
byte[]. The data is stored in an “implementation
-
dependent backing store”. The standard J2SE 1.4 from
Sun uses the registry on Windows, and XML
-
encoded files on Solaris and Linux. These J2SE “central
reposi
tories” are host
-
specific, and can be concurrently updated by multiple JVMS and/or multiple threads
within a JVM. It is expected that there will be various J2EE implementations that provide intranet or even
internet
-
wide central repositories using LDAP, JN
DI, etc. whose details will be hidden from the application
programmer.


The
java.utils.prefs

design goals include organizing the chaos of multiple application
configuration files into a central location, and the ability to share preferences across applicat
ions. It will
likely become an important standard widely used in Java applications.



2

The main problem with using Preferences for our development is the lack of “stored default”
capabilities. We need the ability to create sets of Preferences that can be se
parately managed by developers,
by site managers, by a teacher in the classroom, and by the end
-
user. We also prefer a uniform
implementation across platforms, and the capability of hand
-
editing the Preferences, which can
occasionally solve difficult “back
wards
-
compatible” problems. We also want support for easily storing
more complicated things than primitives and Strings, although we have found Object serialization to be
unacceptably brittle.


The
ucar.util.prefs

package (aka
PreferencesExt
) is an altern
ative implementation of
java.util.prefs
, which makes different design tradeoffs. Our implementation uniformly uses XML files as
backing store across all supported platforms. This provides the possibly of hand editing if needed. Our
XMLStore
files

can be c
hained together, in which case their sets of Preferences are kept separate internally
and create a hierarchy of default values, which override values later in the chain. We also add
set/getBean()

methods which use
reflection to store simple bean objects th
rough their “bean properties”
that use the get/set javabean conventions
.

We also add the
setBeanObject()

method which use the
javax.beans.XMLEncoder/ Decoder

classes to
store

arbitrary objects using persistence.


On the other hand, our
PreferencesExt

impl
ementation
does not currently
provide synchronized
access to the backing store files, nor to support locating them in an application
-
independent way. This
feature could conceivably be added later if it became important, with minimal impact on applications
using
the PreferencesExt API.

2.0
Using PreferencesExt


The Preferences package
easily
allow
s alternate implementations

using a “Service Provider
Interface” (SPI). PreferencesExt uses this SPI to create a subclass of
java.util.prefs.Preferences

called
u
car.util.prefs.PreferencesExt

. Generally an application needs to make PreferencesExt
-
specific calls only during startup and when saving the current set of Preferences, and otherwise can use
objects of type
Preferences

unless they need to call
get
Bean,
set
Bean()
,
and

setBeanObject()

methods.


2.1
Initializing and saving Chained Preference Stores


A typical scenario for chained Stores might have application default values delivered in the
application jar file. A site manager might add other preferences in a
site
-
specific file that augment the
application default values, and override them if they conflict. When first starting an application, the User
Store is empty, but any changes are stored in the User Store to be used when the application next starts.






Fig 1: Chained Preference Stores


When asked for a Preferences value, the
chained Preference
Stores are always checked in
sequence. When storing a Preferences key/value, the Stores are first checked to see if that Preference exists
and if it already has
the exact value. If not, then it is stored in the first Store, in this example the User Store.
So an application can only make changes to the first Store in the chain. This allows applications to save any
Preferences without regard to where it originally c
ame from. Only changed Preferences are saved in the
first Store. Thus, the application defaults or the site manager can make changes that would be seen by the
application, unless the user has already overridden that setting.


The code for initializing the
above chain of stores might look like:

User

Site

Sys

Query :


3



XMLStore store = null;


try {


XMLStore sys = XMLStore.createFromResource("/auxdata/system
.xml
", null);


XMLStore site = XMLStore.createFromFile("/usr/local/metapps/site
.xml
", sys);


store = XMLStore.createFro
mFile("/home/username/user
.xml
", site);


} catch (java.io.IOException e) {


System.out.println("XMLStore Creation failed "+e);


}


PreferencesExt prefs = store.getPreferences();



Upon application exit (or whenever the application chooses), changes to pr
eferences can be saved:



try {


store.save();


} catch (java.io.IOException e) {


System.out.println("XMLStore Save failed "+e);


}


Note that the first
XMLStore
is created by calling
XMLStore.createFromResource,

which will locate
files relative to th
e classpath, including from within jar files. These Stores are always read
-
only. The
second
XMLStore
is created chained to the first, and the third store is chained to the second. All further
manipulation is done through the
PreferencesExt
object obtained
from the third store. There is no way
for an application to determine from which chained Store a Preference comes from (unless it opens them
independently).



[Note that there is currently no synchronization when
multiple threads or JVMs use the same Store

file
.
This is an important difference with the standard Preferences implementation. PreferencesExt Stores should
be saved from a single application thread. Stores that are read
-
only (ones that are not the first Store in the
chain) can be shared, however.]

2.2
Working with Preferences nodes

and primitive values


Preferences (and therefore its subclass PreferencesExt) are organized in a tree of
nodes
. Each node
may contain its own collection of key/value pairs, which are thus contained in separate namespaces
.
Locating a Preferences value is a matter of locating the node it is stored in, and then obtaining the value
from the node

using its key
. The nodes are named as in a hierarchical file directory, with the root node
named “/”, and subno
de names separated by

“/” e.g.
/debugFlags/grids

indicates a

Preferences node called
grids

whose parent is a node named
debugFlags

whose parent is the root node. Nodes can also be named
relative to their parent, so that the two code fragments below are equivalent:



Preference
s prefs = store.getPreferences(); // root node


Preferences gridPrefs = prefs.node(
"
/debugFlags/grids
"
);



Preferences prefs = store.getPreferences(); // root node


Preferences flags = prefs.node(
"
debugFlags
"
);


Preferences gridPrefs = flags.node(
"
grids
"
);


Having
found

the correct node,
obtain

a value from it using a type
-
specific method:



String who = gridPrefs.get(
"customer"
,

null
);


int howMuch = gridPrefs.getInt("quantity", 99);


double cost = gridPrefs.getDouble("dollars", 12.99);


Note that a def
ault is always supplied, and is returned if a value with the specified key does not exist.
Saving values into a Preferences node is similar:



4


gridPrefs.put(
"customer"
,
who
);


gridPrefs.putInt(
"quantity"
, howMuch);


Note that these are not stored on disk u
ntil
save()

is called on the XMLStore object
.


Most of the primitive data types, as well as String and byte arrays
have get methods

provided:



String
get
( String key, String default);


boolean
getBoolean
( String key, boolean default);


byte[]
getByteArra
y
( String key, byte[] default);


double
getDouble
( String key, double default);


float
getFloat
( String key, float default);


int
getInt
( String key, int default);


long
getLong
( String key, long default);


along with

the corresponding put methods:



void
put( String key, String value);


void put
Boolean
( String key, boolean
value
);


void put
ByteArray
( String key, byte[]

value
);


void put
Double
( String key, double
value
);


void put
Float
( String key, float
value
);


void put
Int
( String key, int
value
);


void p
ut
Long
( String key, long
value
);



2.3
Storing bean objects


Th
e

above methods work on primitive types, Strings and byte arrays. The
re are two
ways to store

Java
objects in the XMLStore file,
as
simple beans

and as
bean objects
. Simple beans are relatively

fast to
store and retrieve,
and are
appropriate for objects that are collections of primitive fields, such as in a
relational database. Bean objects are
used
for more complicated objects that may have nested objects
inside.
In both cases, by default your
Bean class must have a no
-
argument constructor. Also, t
he
Bean

class
must be available in the application that reads the Preferences file; if not, that object will be discarded.


Use

the

putBeanObject()

method
to store arbitrary objects using java.beans.XM
LEncoder. This
JDK
1.4 class
was especially designed to handle user interface components such as
those

in the
java.awt

and
javax.swing

packages.
It

handles arbitrary
graphs of Java
object
s
.
By default, the class must have a no
-
argument constructor. However,

you can create “custom persistence delegates” to get around that, or for
any other special processing.
See the
XMLEncoder
javadoc and the series of articles at
http://java.sun.c
om/products/jfc/tsc/articles/persistence2/

for more information.



Use

the

putBean()

method w
hen you have
a simple object

that follow
s

javabean get/set
conventions

and has a no
-
argument constructor
. This provides
relatively high

performance
(see Appendix
)
and
a simpl

XML representation. Reflection i
s used to find all non
-
indexed J
avabean properties
of
primitive,
String
, or Date

type. Other property types, nested objects, and indexed properties are ignored.
When you
need to store

a collection of
these
simp
le beans
,

use
the
putBean
Collection
()

method.



Object getBean(String

key,

Object

def
ault
)
;


void

pu
tBean(String

key,

Object

bean
)
;


void

pu
tBean
Object
(String

key,

Object

bean
)
;


void

pu
tBean
Collection
(String

key,

Collection

beans
)
;


No matter how the
object was stored, use the
getBean()

method to retrieve the object.
Note that when
using
putBean()
, each bean is given a key, whereas for a
putBeanCollection()
, the entire collection
is
named by the

key
.



5

These
methods extend the java.util.Preferences API
,

so you must cast the
Preferences
object
to a

PreferencesExt
object:



PreferencesExt prefsExt = (PreferencesExt)
prefs
;


Object bean = prefsExt.getBean("what", null);


if ((bean != null) && (bean instanceof Garbanzo)) {


gbean = (Garbanzo) bean;


gbe
an = (Garbanzo) gbean.clone(); // Make a copy
somehow
!!!!


}




...


prefsExt
.putBean(
"
what
"
, gbean);


NOTE THAT IF YOU CHANGE A BEAN
and store the changes you should work with a
copy of the bean
.

The reason is that if the bean comes from a stored default
, the new value will not be
saved if you work directly with the bean, since you will be changing the original object. (The problem is
there is no general way to copy an object.
LOOK FIX THIS!
).
This problem does not occur with bean
collections.


2.4
Settin
g the default Preferences


It is often c
onvenient to set an application
-
global default Preferences store, so that you do not have
to pass around the Preferences object everywhere in your code. The
Preferences

package provides static
methods for accessing the default Preferences, one for the default User Store and one for the default System
Store:



java.util.prefs.
Preferenc
es
.userRoot();


java.util.prefs.
Preferences
.systemRoot()


To use these calls with PreferencesExt, you must first create the PreferencesExt store and explicitly set it as
the default:



X
MLStore userStore = null;


XMLStore sysStore = null;


try {


userStore = XMLStore.createFromFile("/home/username/user
.xml
", null);


sysStore = XMLStore.createFromFile("/local/app/site
.xml
", null);


} catch (java.io.IOException e) {


System.out.printl
n("XMLStore Creation failed "+e);


}


PreferencesExt.setUserRoot(userStore.getPreferences());


PreferencesExt.setSystemRoot(sysStore.getPreferences());


You must also tell the PreferencesFactory to use our PreferencesExtFactory:



System.setProperty("java
.util.prefs.PreferencesFactory",


"ucar.util.prefs.PreferencesExtFactory");


You must set up the
PreferencesExt

store and set the Factory before any calls are made to
Preferences
.userRoot(
)

or

Preferences
.systemRoot().



3.0
User Interface Classes



6

These are utility classes in the
ucar.util.prefs.ui

package that build on top of the Preferences and
PreferencesExt APIs.

3.1
D
ebug


The
Debug

class provides static methods for managing persistent lists of debugging flags that can be set by
the user at runtime. A new debug flag is added to the Store whenever
isSet()

is called and the flag name
does not already exist. The flags ca
n be set dynamically at runtime through a JMenu, with the name of the
flag used for the menu label, and the “/” separator indicating menu levels (see Fig 2.). Note that this class
does not depend on using
PreferencesExt
, and so could also be used with the
default
Preferences
implementations.


public class Debug {


public static void setStore(java.util.prefs.Preferences

mainStore);


public static boolean isSet(String flagName);


public static void set(String flagName, boolean value);


public stat
ic void constructMenu(javax.swing.JMenu);

}


To use, make sure that you call
setStore()

before anything else; it is a good idea to use a separate node
to avoid name collisions:



Debug.setStore(prefs.node(“/debugFlags”));


To allow user control at runtime
, add a
JMenu

instance variable to your main menu, which constructs itself
whenever it is called using the current set of flags, e.g.:



JRootPane rootPane = getRootPaneContainer().getRootPane();


JMenuBar mb = new JMenuBar();


rootPane.setJMenuBar(mb);


JMenu sysMenu = new JMenu("System");


mb.add(sysMenu);



JMenu debugMenu = (JMenu) sysMenu.add(new JMenu("Debug"));


debugMenu.addMenuListener( new MenuListener() {


public void menuSelected(MenuEvent e) { Debug.constructMenu(debugMenu);}


publ
ic void menuDeselected(MenuEvent e) {}


public void menuCanceled(MenuEvent e) {}


});


sysMenu.add(debugMenu);



Then in your application code, check to see if a debug flag is turned on, for example:



if (Debug.isSet("util/configure/stuff")) do_go
od_stuff();


The first time this code is called, this flag will be added to the Store and to the menu (with a value of false).
The user can then turn it on using the menu system. This allows you to add fine
-
grained debugging control
without having to manag
e a separate list of flags. Since these are all static methods, you do not have to pass
around a global Debug object. In this example, the top menu item to be added will be called “util” the
second item called “configure”, and the flag itself will be calle
d “stuff”. The menu may nest to arbitrary
depth. Similarly, a substore of the main debug Store (the one passed into
setStore())

is created called
“util”, which has a substore called “configure”, which has a boolean value whose key is “stuff”. Thus name
col
lisions should be easy to avoid.



7



Fig 2: Example use of Debug Menu



3.2 ComboBox


A
ucar.util.prefs.ui.
ComboBox

is a simple extension to JComboBox , which keeps the
N

latest selected
values in a PreferencesExt object. The JComboBox is editable, and
a
u
ser can enter a new String.
When a
selection is made, an ActionEvent is sent. T
he calling routine should
check for validity,
transform it to
the
correct object type

if needed,

and call
addItem()
.

This placed the selected item on the
on the top of the list,

so
least recently used items are eventually dropped off the list.



The items in the list can be any Object type with these caveats:



item.toString()

is
used
for

the
display name



item.equals()

is used to

test for
object equality



prefs.putBeanObject()

is

us
ed for storage, which uses

java.beans.
XMLEncoder

for serialization,

so
the class

must have
a
no
-
arg
ument

Constructor.

3.3

Field


A
ucar.util.prefs.ui.Field

is the abstract superclass for data input fields that have a Preferences object to
make their inpu
t values persistent. When an application starts up, the initial value of the field is obtained
from the Preferences object, and any changes to the Field are automatically stored there. The application
can therefore query the Preferences object directly for

the value, and does not need to know about the data
input field. A PropertyChangeListener can also be added to listen for changes in the Field’s value.


Custom handling and layout of Fields can be done by obtaining the field label and editComponent and
w
orking with them as usual within a Swing/AWT GUI framework. The
PrefPanel

class (see below)
provides a way to construct standard dialogs for managing user preferences.


8


The public interface is:


public abstract class Field {


public String getName();
// Preferences key


public JLabel getLabel();


public JComponent getEditComponent();



public boolean isEnabled(); // same as for JComponent


public void setEnabled(boolean);


public void setToolTipText(String tip);



public void addPropertyChan
geListener(java.beans.PropertyChangeListener);


public void removePropertyChangeListener(java.beans.PropertyChangeListener);

}


Standard Field subclasses

These are the standard Field subtypes for data
input. Note that all except
Combo and TextFormatted ta
ke a
Preferences object, and so can be used with the default
Preferences
implementations.


Field subclass


DataType

JComponent

Field.CheckBox

boolean

JCheckBox

Field.Date


Date


JFormattedTextField

Field.Double


double


JFormattedTextField

Field.Int


int


JFormattedTextField

Field.Password

String


JPasswordField

Field.Text


String


JTextField

Field.
Combo


Object


ComboBox

Field.TextFormatted

Object


JFormattedTextField



These are the calls for extracting
specific

Field
subclass
values:



boolean Field.Ch
eckBox
.
isSelected
(
);


Date Field.Date
.
getDate(
);


double Field.Double
.get
Double(
);


int Field.Int
.get
Int(
);


char[] Field.Password
.getPassword
(
);


char[] Field.Password
.getPassword
(
);


String Field.Text
.getText()
;


String Field.TextCombo
.getTex
t()
;


String Field.TextFormatted
.getText()
;



Creating custom Field subclasses

A user can create their own subclass of
Field

, which can be used alone or with the
PrefPanel

class. The
abstract methods
to

implement are:



/** Return the editing JComponent

*/


abstract public JComponent getEditComponent();



/** get current value from editComponent */


abstract protected Object getEditValue();



/** set value of editComponent */


abstract void
setEditValue
(Object value);



/** get value from Store, ma
y return null */


9


abstract protected Object getStoreValue(Object defValue);



/** put new value into Store */


abstract protected void setStoreValue(Object newValue);



3.4

PrefPanel


A PrefPanel manages a set of Fields with convenience methods for rapi
dly creating User Dialogs whose
values are made persistent by a Preferences Store. All Fields contained in the PrefPanel share the same
Preferences, and so must have unique names.
The public API:


public class PrefPanel extends javax.swing.JPanel {


publi
c PrefPanel(String title, Preferences store);


public String getName();



// send ActionEvent when accept() is called


public void addActionListener(java.awt.event.ActionListener);


public void removeActionListener(java.awt.event.ActionListener);


pub
lic void accept(); // programmatically hit “accept” button




// panel layout


public void addButton(javax.swing.JComponent); // to button panel


public void addHeading(java.lang.String); // group heading


public void addSeparator(); /
/ after last field added


public void newColumn(); // start a new column



// add Fields to the panel


public
Field

addField(
Field

fld); // add custom made fields


public Field.CheckBox addCheckBoxField(String name, String lab, boolean def);


public Field.Date addDateField(Strin
g name, String label, Date def);


public Field.Double addDoubleField(String name, String label, double def);


public Field.Int addIntField(String name, String lab, int def);


public Field.Password addPasswordField(String name, String lab, String def);



public Field.Text addTextField(String name, String label, String def);


public Field.Combo add
ComboField(String name, String label,

List defs, int nKeep);


public
Field.TextFormatted

addTextFormattedField(String

fldName, String

label,


JFormattedTextField.AbstractFormatter

format, Object

defValue)



public void finish(); // call when all done

}


Here is an example

of using a PrefPanel
with a Preferences store.

Note that the values are obtained from
the Preferences by using the Field name
.



S
tring TAS_URL = "ServletURL";


String SERVER_NAME = "
ServerN
ame";



PrefPanel topPP = new PrefPanel("topPanel", prefs);


topPP.addTextComboField(T
AS_URL, "Servlet URL", null, 5);


topPP.newColumn();


topPP.addTextComboField(SERVER_NAME, "Server Name", null, 5);


topPP.finish(true, BorderLayout.EAST);



topPP.addActionListener(new ActionListener() {


public void actionPerformed(ActionEvent e) {



String tas = prefs.get(TAS_URL, null);



String name = prefs.get(SERVER_NAME,null);


process( tas, name);


10


}


});


It creates this panel:




PrefPanel Example 1



Here is an example of using PrefPa
nel without a Preferences store. Note here we keep
references to the
Fields, in order to get the values from them. We also add a “cancel” button using PrefPanel.addButton().



private Field.Text userF;


private Field.Password passwF;


PrefPanel

pp = new PrefPanel("UrlAuthenticatorDialog", null);


userF

= pp.addTextField("user", "User", " ");


passwF = pp.addPasswordField("password", "Password", " ");



pp.addActionListener(new ActionListener() {


public void actionPerformed(ActionEvent e) {



pwa = new PasswordAuthenticatio
n(userF.getText(), passwF.getPassword());



dialog.setVisible( false);



}


});




JButton cancel = new JButton("Cancel");

// button to dismiss


pp.addButton(cancel);


cancel.addActionListener( new ActionListener() {


public void actionPerform
ed(ActionEvent evt) {



pwa = null;



dialog.setVisible( false);


}


});


pp.finish();


It creates this panel:




PrefPanel Example 2


Resizeable Fields


Most of the fields that are added to a PrefPanel
are
resizeable

by the user.

These appear w
ith a double bar
on their right side. To resize these, the user clicks and releases the double bar. The bar turns a different
color (see picture). Then by clicking and dragging on the bar, the user can resize the width of the Field.




11


PrefPanel.Dialog

A
convenience class for constructing a standalone JDialog window that has a PrefPanel inside it. To show
it on screen, call dialog.show(). Example:



PrefPanel.Dialog d = new PrefPanel.Dialog( frame, true, "testDialogue",


(PreferencesEx
t) store.node("dialog"));


PrefPanel pp2 = d.getPrefPanel();


pp2.addHeading("This is Not Your Life:");


pp2.addTextField("name", "name", "defValue");


pp2.addTextField("name2", "name2", "defValue22");


pp2.addTextField("name3", "name3", "defValue22 asd ja
lskdjalksjd");


pp2.addSeparator();


pp2.addHeading("Part Two:");


pp2.addPasswordField("password", "password", "secret");


pp2.addIntField("testInt", "testInt", 1234);


pp2.addDoubleField("testD", "testD", 1234.45);


pp2.addCheckBoxField("testB", "testB",

true);


pp2.newColumn();


pp2.addHeading("Another Column:");


pp2.addDateField("date", "date", new Date());


try {


pp2.addTextFormattedField("ff", "ff",

new javax.swing.text.MaskFormatter("(###) ###
-
####"), "(303) 497
-
1234");


} catch (java.text.Parse
Exception e) { }


ArrayList list = new ArrayList(5);


list.add("this");


list.add("is");


list.add("new");


list.add("but");


list.add("really too longs");


pp2.add
ComboField("combo", "combo", list, 5);



d.finish();


d.show();


creates the Dialog box seen

in Figure 3.




PrefPanel.Dialog Example 3


12


3.5

BeanTable
, BeanTableSorted


A
BeanTable

is a widget that displays collections of simple beans in a JTable.

Each bean property becomes
a column in the table; each bean is a row. A
BeanTableSorted

is a subcl
ass that allows sorting on the
column values.




public BeanTableSorted( Class b
eanClass
, PreferencesExt pstore, boolean
canAddDelete)
;


Example of use:



beanTable = new BeanTableSorted(DatasetBean.class, dbPrefs, false);


With this bean class:


public c
lass DatasetBean {


private String groupName, datasetName, title;


private boolean include;


private String monitorType;


private int dataFreq, dataLatency, serverCalls;


private double misses, serverTime;


private Date monitorOffUntil;



// no
-
arg
constructor


public DatasetBean() {}



public String getGroupName() { return groupName; }


public void setGroupName(String groupName) { this.groupName = groupName; }



public String getDatasetName() { return datasetName; }


public void setDatasetName(

String name) { this.datasetName = name; }



public String getTitle() { return title; }


public void setTitle( String name) { this.title = title; }



public boolean isInclude() { return include; }


public void setInclude(boolean include) { this.include

= include; }



public String getMonitorType() { return monitorType; }


public void setMonitorType(String mtype) { this.monitorType = mtype; }



/** data frequency in seconds */


public int getDataFreq() { return dataFreq; }


public void setDataFreq(i
nt dataFreq) { this.dataFreq = dataFreq; }



/** seconds between nominal data time and data available at server */


public int getDataLatency() { return dataLatency; }


public void setDataLatency(int dataL
atency) {this.dataLatency = dataLatency;
}



/**

avg number of server misses per new data, on current server run*/


public double getMisses() { return misses; }


public void setMisses(double misses) { this.misses = misses; }



/** total server time taken, on current server run*/


public double getSe
rverTime() { return serverTime; }


public void setServerTime(double serverTime) { this.serverTime = serverTime;
}



13


/** number of server calls, on current server run*/


public int getServerCalls() { return serverCalls; }


public void se
tServerCalls(int

serverCalls) {this.serverCalls = serverCalls;
}



public Date getMonitorOffUntil() { return monitorOffUntil; }


public void setMonitorOffUntil(Date mtype) { this.monitorOffUntil =
monitorOffUntil; }


}


Cre
ates this

B
eanTable

widget
:





BeanTable widge
t

14

References


1) The java.util.prefs API :
http://java.sun.com/j2se/1.4/docs/guide/lang/preferences.html


2) Javabean persistence:
http://java.sun.com/j2se/1.4/docs/guide/beans/index.html




Appendix

A. Bean t
iming tests


Time (msec) to read/write
test
objects





1000 objects


2000
objects


file size




write

read


write

read

(Kb)


bean
Object

2554

661

4877

1332


2159




bean


471

130

821

230



981

beanCollection

330


80

581

160



858


Appendix B. XML file format


Here is a simple
but complete
XML
Store
file, with

2 nodes under the root:


<?xml ver
sion="1.0" encoding="UTF
-
8"?>

<preferences EXTERNAL_XML_VERSION="1.0">


<root type="user">



<map/>



<node name="
node1
">




<map>





<entry key="TestBoolean" value="false"/>





<entry key="TestDouble" value="3.14156"/>





<entry key="TestDoubleInt" val
ue="111.0"/>





<entry key="num_cols" value="180"/>





<entry key="num_rows" value="140"/>




</map>




<node name="
node2
">





<map>






<entry key="an entry" value="value entry"/>





</map>




</node>



</node>


</root>

</preferences>



A beanObject
is stored
,

for example:





<beanObject key="
my
BeanObject">





<object class="ucar.util.prefs.TesterBean">






<void property="b">







<boolean>false</boolean>






</void>






<void property="d">







<double>1.099E
-
5</double>






</void>


15






<voi
d property="i">







<int>9999</int>






</void>






<void property="s">







<string>changedo</string>






</void>





</object>




</beanObject>



A
n object stored as a simple bean looks lik
e, eg
:


<bean key="my
Bean" class="ucar.util.prefs.TesterBea
n" b="false"


byte="100" d="1.099E
-
5" f="0.99" i="9999" l="123456789" s="changed"


short="666"/>


A bean collection looks like, eg:



<beanCollection key='
myArray’
class='ucar.util.prefs.TestDBBean$DBBean'>


<bean
name=’trial 1’ avg
= 0.2965785406003758'

std
= 0.8790711576832737'
/>


<bean
name=’trial 2’ avg
=

0.
65785406003758'
std
=

0.
0711576832737'
/>


...


</beanCollection>