It has been much pleasure to look at this fresh approach. While hsql
database file does not seem to be particularly user-friendly when it comes
to manual editing the rest of it is really great. To my thought one of the
strongest points of the implementation is that the DataMaps used to define
the preference objects provide quite nice preference metadata which is an
important but nevertheless nearly always overlooked feature.
Now, here is one serious criticism. In principle it is considired to be
mandatory behavior of a good preference management implementation that it be
fault tolerant especially with respect to preference file corruptions.
First, if some stored values are found incorrect or missing (possibly due to
mistakes made when editing the file manually) the framework must fall back
to the read-only defaults preferably stored in the same format as the
regular preferences, or some values can normally be stored per user but
still be backed up per community, for instance, or exist only in the wider
scope of an entire site or organization. Second, if a preferences file is
found misformatted or is missing it must be regenerated silently and
prefilled with those defaults. While your approach almost certainly has got
enough potential to deal with these tasks at the level of elegance,
currently I caused the application to fail completely by misformatting or
inserting NULL values into its db.script. Let me reassert, I believe the
fault tolerance is a must here as a wrong (NULL, for example) window
position value stored in the preferences file simply has no right and no
slightest excuse for killing the application on startup ever.
And once again, your idea is really, really good!
Andriy.
----- Original Message -----
From: "Andrus Adamchik" <andru..bjectstyle.org>
To: "Cayenne Devel" <cayenne-deve..bjectstyle.org>
Sent: Wednesday, September 22, 2004 8:38 PM
Subject: Modeler Preferences
> Long time ago we had a discussion with Andriy about a need for a usable
> preferences API in Java (beyond the java.util.prefs "invention"). Now
> that I had an immediate need for such API to use for Modeler
> Preferences, I had to actually design one myself. I needed the
> following features:
>
> * Hierarchical preferences with the ability to easily locate a
> preference object for a given Java object in a certain context.
> * Platform independent storage format that is human-readable and
> editable in a simple text editor.
> * An ability to retrieve typed objects, not just some key value pairs
> (e.g. have a "db connection" preference object for a DataNode that
> stores URL, driver, password, etc.)
>
> Looking at this list I couldn't think of a better way, but to use
> Cayenne itself as a base for such preference API implementation. So I
> created a small preference framework that has a "common" part (DataMap)
> used for preference organization and lookup and a "domain-specific"
> part (which is a DataMap created by developer for her specific
> application). Here is an implementation of this idea:
>
> http://objectstyle.org/downloads/cayenne/demos/ModelerPreferences.tar.gz
>
> This is an Eclipse project that depends on Cayenne, that contains a
> common preferences library and a small Swing app that implements a
> preference editor for DataSources. It uses an embedded HSQLDB (with
> files created under ~/.cayenne/pref/ - no need to do "generate DB", it
> bootstraps itself automatically). This actually worked *very* well, and
> I think such approach should work with any GUI application. My only
> concern is HSQL DB itself - we can't use a standalone server, as this
> will hurt Modeler usability. And the embedded DB mode doesn't allow
> multiple processes to modify the same DB. So I had to implement various
> tricks to get around this limitation. E.g. if you open multiple
> instances of the app, I am cloning the DB. I guess at some point we
> should open multiple frames of in the SAME JVM, instead of multiple
> instances.
>
> As this implementation will be a part of the Modeler in Cayenne RC1, I
> appreciate comments on the tool and general approach.
>
> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Wed Sep 22 2004 - 16:03:07 EDT