summaryrefslogtreecommitdiff
path: root/xmerge/source/xmerge/java/org/openoffice/xmerge/package.html
diff options
context:
space:
mode:
Diffstat (limited to 'xmerge/source/xmerge/java/org/openoffice/xmerge/package.html')
-rw-r--r--xmerge/source/xmerge/java/org/openoffice/xmerge/package.html113
1 files changed, 113 insertions, 0 deletions
diff --git a/xmerge/source/xmerge/java/org/openoffice/xmerge/package.html b/xmerge/source/xmerge/java/org/openoffice/xmerge/package.html
new file mode 100644
index 000000000000..ea56e3b6c118
--- /dev/null
+++ b/xmerge/source/xmerge/java/org/openoffice/xmerge/package.html
@@ -0,0 +1,113 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<!--
+ #*************************************************************************
+ #
+ DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+
+ Copyright 2000, 2010 Oracle and/or its affiliates.
+
+ OpenOffice.org - a multi-platform office productivity suite
+
+ This file is part of OpenOffice.org.
+
+ OpenOffice.org is free software: you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License version 3
+ only, as published by the Free Software Foundation.
+
+ OpenOffice.org 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 version 3 for more details
+ (a copy is included in the LICENSE file that accompanied this code).
+
+ You should have received a copy of the GNU Lesser General Public License
+ version 3 along with OpenOffice.org. If not, see
+ <http://www.openoffice.org/license.html>
+ for a copy of the LGPLv3 License.
+
+ #*************************************************************************
+ -->
+<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 &quot;merge&quot; interface for merging back
+changes from a &quot;lossy&quot; 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 &quot;Device&quot;
+to &quot;Office&quot;) and/or serialization (convert from
+&quot;Office&quot; to &quot;Device&quot;). If a plug-in supports
+both deserialization and serialization, then it can also support
+&quot;merge&quot;.</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 &quot;merge&quot; those
+changes back into the original &quot;rich&quot; <code>Document</code>.
+Each merge implementation provides a <code>ConverterCapabilities</code>
+implementation so that the merge logic knows what changes from the
+&quot;lossy&quot; format to merge into the original &quot;rich&quot;
+<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 &quot;rich&quot;
+ <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>
+