[daisy] Daisy Detachment - updates

[Marc Portier]

tim_cranfield at goldenboat.net wrote:
> I committed quite a few changes to the detachment project:
> https://svn.cocoondev.org/repos/daisy/contrib/gsoc2006/tim/
> 
> Unfortunately most of the commit message was lost when I tried to paste
> it to the command line, so here it is:

if you use eclipse synchronization perspective it's easy to add
multi-line log-messages in the commit-dialog screen

on the cli you can ommit the -m and then svn should pop-up a text-editor
to edit the comment-log, as soon as you close the editor, the saved
temp-file is picked up by svn and used as comment-log

> 1)Moved daisy icon to DetachmentGUI directory and removed icons
> directory, also changing the way it is accessed in the code, as per
> discussion:
> http://lists.cocoondev.org/pipermail/daisy/2006-June/004317.html

nice,

by the way: did you actually test this:

association.setIconFileName(DetachmentGUI.class.getResource("daisy.png").getPath());

when the png is in the jar and not in the target/classes ?
(in that case the getPath() will end up yielding a URL that looks like
file:/path-to/ddzgui-2.0-dev.jar!/org/outerj/daisy/detachment/gui/daisy.png
and not
/path-to-project/target/classes/org/outerj/daisy/detachment/gui/daisy.png
which might make quite a big difference)

> 2)Added a ConnectionInfos class to allow connections to be persisted
> through serialization

I noticed you introduced manual serialVersionUID fields for this

it is recommended to use the JAVA_HOME/bin/serialver tool to generate a
more common looking serialVersionUID's for your classes, and then manage
it properly to avoid ser-deser mishaps

this value should act as a fingerprint for the class (so it's really
uncommon to have various classes bare the same)

I also noticed you're adding those to GUI elements (panel's)
my first reaction would be to avoid serializing GUI components, dunno if
others have different experiences to share on this...

well, this is probably about internal stuff anyway so it doesn't really
matter, but in general I wouldn't mind having that info in readable
(editable) xml files in stead of java-ser files?

> 3)Removed ConnectionPanel from frame and put it into a JDialog
> 4)Serialize ConnectionInfos on close of frame for re-use next time.
> 5)Removed getCurrentDocument() method from DetachmentManager as it was
> not used.
> 6)Created getXmlString() methods in DetachmentPart, DetachmentField and
> DetachmentLink and DetachmentLinks for use by XmlHandler for writing
> 'content.xml' file.

hm, I saw your are just using stringbuffer.append for this
I'ld rather see us use xmlbeans for this stuff, (or sax)

not using an established framework for serializing out xml makes you
responsible for low level stuff as introducing required character
entities (e.g. see how a document.name holding a " char would yield
xml-syntax well-formedness errors)

xmlbeans will also take care of the other aspects of well-formedness
(e.g. forgetting to close an element) and the xml-namespace stuff

> 7)Moved Main method to new class 'Main'in DetachmentGUI and made
> DetachmentGui instantiate DetachmentManager as per discussion:
>  http://lists.cocoondev.org/pipermail/daisy/2006-June/004307.html
> 8)Removed Swing usage from DetachmentManager package as per discussion:
> http://lists.cocoondev.org/pipermail/daisy/2006-June/004307.html
> 9)Changed gui package name from detachmentGUI to detachment.gui as per
> discussion:
> http://lists.cocoondev.org/pipermail/daisy/2006-June/004307.html
> 

cool!


> 
> The next steps in the project will be:
> 1)Allowing add/edit/delete operations on detachment parts and fields.
> 2)Uploading back to the repository.
> 3)Make the detachment package strictly an API provider - remove any
> dependencies it has on the gui package. The gui is an implementation of
> the DetachmentView interface. At the moment the detachment package uses
> some of the methods of the DetachmentView interface to send or retrieve
> information. This is not consistent with the idea of the detachment
> package being just a service provider.
> 

perfect

> Design documents are here:
> http://cocoondev.org/daisyscratchpad/g5/309.html
> 

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo at outerthought.org                              mpo at apache.org