standard saving loading projects paradigm

Hello,

I've got this common problem that I am sure has been solved before.

Ok first picture my application...

It's a standard GUI with a tree on the left (some sort of package explorer) and a tabbed pane on the right with closeable tabs.

Clicking on the tree nodes closes/opens tabs.

Pretty much like the Eclipse IDE or any other standard IDE.

Now this I'm trying to do...

I want to save/load projects represented in my application by a JTree. My idea is to serialize/deserialize the TreeModel of the JTree. This will involve de/serializing all objects referred to by the TreeModel i.e. all the DefaultMutableTreeNodes as well as all other objects that may be referred by the nodes (unless declared transient). These objects include a tab aswell as a file from which the contents of the tab are loaded.

To tackle this problem I suspect I'll probably have to use Java de/serialization and/or the XMLEncoder/Decoder bean.

So my questions boil down to:

Does anyone know of any API (an open source project) which solves this problem already?

If not, is there a paradigm, a standard way of dealing with this problem?

I.e. has anyone solved this problem before and how?

Does the transient keyword work with XMLEncoder?

Regards,

--

Nikolas.

[1354 byte] By [nikolas_pontikosa] at [2007-10-2 12:44:34]
# 1

I am not aware of any API that solves this problem, but that's not saying much. :)

I would honestly store the view of the project in a different data structure having little or nothing to do with your GUI (in this case, Swing). I'd make that Serializable and each node in that tree structure would contain the appropriate data. Then I would serialize that data when I saved the file.

The TreeModel that I'd use would be written to be backed by that data structure; thus, you'd pass that data structure to the TreeModel's implementation's constructor. When you read the tree structure back in from the data file, you just create the TreeModel and hand that to your JTree.

If you particularly want to save the Swing TreeModel object, I must admit that it would probably be very simple. Just write the TreeModel to the ObjectOutputStream and everything inside of it goes right in. You'd have to store your tabs separately unless, for some odd reason, the nodes referred to them.

Best of luck. :)

tvynra at 2007-7-13 9:52:09 > top of Java-index,Core,Core APIs...
# 2
Cheers for your answer.Yeah the way I solved this problem is by serializing the tree model which involved serializing the tree nodes. Tree nodes refer to a file and a tab. So I declared the tab field transient.Thanks,--Nikolas.
nikolas_pontikosa at 2007-7-13 9:52:09 > top of Java-index,Core,Core APIs...
# 3

As a related question I am interested in your opinion.

With larger applications do you think that centralising the persistant data structures to one, or a small number of roots, is a good thing or not? I have tended to do this but recently I have read advice which sggests just the opposite. This almost suggests to me that in a development team we might even lose sight of how many, and which parts of the application, are using persistance functions. I have mis-givings about that.

I think the point is that restoring parts of a save state is of course a common requirement but I feel that handling ALL the elements saved will also be an ongoing requirement as an application is maintained, extended re-ported etc.

Would you recommend one common root?

Gargoylea at 2007-7-13 9:52:09 > top of Java-index,Core,Core APIs...
# 4

I'm not sure I understand what you mean by roots.

Are you trying to serialize many trees? Or do you actually mean nodes instead of roots?

Ok anyways from what I understand the issue is what objects to declare as persistent (i.e. implementing serializable interface) and which to make implicitly persistent by say declaring a method which saves/load the object's state to/from a file.

Well I suppose you want to serialize as little as needed and you should avoid serializing swing objects (although I have serialized TreeModel).

It is probably better to provide your own "codec" class or interface for saving loading the state of swing objects. The reason I chose to opt for default serialization was because of time constraints.

So I guess that if you are going to define your own custom serialization then you might have one common root and different serialization methods.

Ok I'm not sure I've answered your question there...

Let me know.

nikolas_pontikosa at 2007-7-13 9:52:09 > top of Java-index,Core,Core APIs...
# 5

> Are you trying to serialize many trees? Or do you

> actually mean nodes instead of roots?

You are right if you don't connect the serialized trees together they must be handled separately. Some people advise me to keep them separate and other people seem to say that it is better in the long run to keep them connected and potentially handled together.

Gargoylea at 2007-7-13 9:52:09 > top of Java-index,Core,Core APIs...