1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--
# The Contents of this file are made available subject to the terms of
# either of the GNU General Public License Version 2.1
#
# GNU Lesser General Public License Version 2.1
# =============================================
# Copyright 2006 by Bruno Mascret
# bmascret@free.fr
# http://natbraille.free.fr
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License version 2.1, as published by the Free Software Foundation.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
#
-->
<html>
<head>
<title>org.openoffice.xmerge package</title>
</head>
<body bgcolor="white">
<p>Provides interfaces for converting between two <code>Document</code>
formats, and supports a "merge" interface for merging back
changes from a "lossy" format back into a rich format.</p>
<p>The {@link org.openoffice.xmerge.Convert
Convert} object encapsulates the conversion of one format to/from another
format. The user requests a <code>Convert</code> object via the
<code>ConverterFactory</code>.</p>
<p>The <code>Convert</code> class encapsulates a specific plug-in.
A plug-in can support deserialization (convert from "Device"
to "Office") and/or serialization (convert from
"Office" to "Device"). If a plug-in supports
both deserialization and serialization, then it can also support
"merge".</p>
<p>To support conversions where a single input <code>Document</code> can
create multiple output <code>Document</code> objects, data is passed in
and out of the conversion functions via a <code>ConvertData</code> object.
This <code>ConvertData</code> can contain one or more <code>Document</code>
objects. It is assumed that the client will know when to pass multiple
files into a specific plug-in, and that the plug-in will know how to
handle the multiple files.</p>
<p>Merging is useful when converting from a rich <code>Document</code>
format to a more lossy format. Then the user may modify the
<code>Document</code> in the lossy format, and "merge" those
changes back into the original "rich" <code>Document</code>.
Each merge implementation provides a <code>ConverterCapabilities</code>
implementation so that the merge logic knows what changes from the
"lossy" format to merge into the original "rich"
<code>Document</code>.</p>
<p>Each plug-in must be registed via the singleton ConverterInfoMgr
object via its {@link
org.openoffice.xmerge.util.registry.ConverterInfoMgr#addPlugIn
addPlugIn} method.</p>
<h2>Providing implementations</h2>
<p>The plug-in implementation must include the <code>getDeviceDocument</code>
and <code>getOfficeDocument</code> methods. These functions need to return
the appropriate type of <code>Document</code> for the plug-in. It may be
necessary to create a new implementation of the <code>Document</code>
interface if one does not exist that meets the needs of the plug-in.</p>
<p>Currently, base implementations for working with StarWriter XML
<code>Document</code> objects are available via the
<a href="converter/xml/sxc/package-summary.html#package_description">
org.openoffice.xmerge.xml.sxw</a>
package, and StarCalc XML <code>Document</code> objects via the
<a href="converter/xml/sxw/package-summary.html#package_description">
org.openoffice.xmerge.xml.sxc</a>
package.</p>
<h2>TODO/IDEAS list</h2>
<p><ol>
<li>An idea is to combine the <code>ConvertData</code> and the
<code>Convert</code> classes, so that a <code>ConvertData</code>
knows what it can convert into and whether or not it can merge.
Then a user would call convert/merge methods on the
<code>ConvertData</code> class, which returns a
<code>ConvertData</code> object that likewise knows what it can
convert/merge into.</li>
<li><code>DocumentSerialize</code> constructors and the
<code>DocumentDeserializer.deserializer</code> method could pass
in a <code>ConvertData</code> object rather than assuming
a single <code>Document</code> will represent a "rich"
<code>Document</code>.</li>
<li>May need to add a <code>PluginFactory.setProperties</code>
method for adding properties specific to each converter.</li>
</ol></p>
</body>
</html>
|
