Feature request: DockFrontend's state persistence via Java's XMLEncoder API

Byte-Welt - Projekte / Projects DockingFrames
1

Hi,

it seems you put quite some effort into reprogramming libraries for serializing component state to XML and other formats.
I would suggest to use the API
http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/beans/XMLEncoder.html
an related classes instead.

This is also the way that regular Swing component’s state is serialized by convention.
The main advantage I could see is

  • better reuse of Java’s standard XML serialization approach

  • easier integration of state serialization of the Swing application framework (will probably become part of JDK 1.7), especially
    with regard to the class SessionStorage:
    https://appframework.dev.java.net/nonav/javadoc/AppFramework-1.03/org/jdesktop/application/SessionStorage.html

  • Methods such as read(), write(), readXML(), writeXML() on DockFrontend could essentially go then.

  • I think, it would also be benefitial to make classes that represent persistable DockFrontend-state implement java.io.Serializable.

Anyway - just suggestions… :stuck_out_tongue:
(and maybe there are relevant points which
counter these thoughts and which I haven’t considered here)

Greetings,

Daniel

2

Ok, there are reasons why I won’t make this now (maybe never). Some of these reasons are better than others :wink:

  1. History
    The first version (we are now in the third iteration) of the layout storage mechanism was quite primitive, written very fast, and supported only byte-streams.
    When storage become more complex, I needed some way to inspect the files that were written. At this point I introduced the XML version. I needed full control over the files that were written, hence things like the XMLEncoder were not an option. On the other hand existing XML-frameworks, like org.w3c.dom offer way too much information than is necessary to write/read simple XML files.

  2. Lazyness
    The current system is working, and changing it would mean to work.

  3. Aversion against Serializable
    I don’t like Serializable and similar mechanisms. They tend to write more than the progammer anticipated, one reference too much and your whole program gets stored.

  4. Not much effort to use
    I don’t think it is much effort to implement the DockFactorys. Most Dockable need to store some reference to the data the show, not the data itself (*). The reference is seldomly much more than a String. Also redirecting the byte- or xml-file into a folder of the user can be done within 30 minutes.

  5. In regard to SessionStorage
    SessionStorage is build on a per component approach. The meta information stored and carried around in DF is not related to specific components. And choosing an arbitrary component to store the DF’s layout information is a rather dubios solution.

(*) Anyone saving data of the model together with layout information of the GUI is doing something very wrong…