Difference between revisions of "Documentation/DevGuide/OfficeDev/Integrating Import and Export Filters"

Revision as of 13:03, 15 February 2008

This section explains the implementation of OpenOffice.org import and export filter components, focusing on filter components. It is intended as a brief introduction for developers who want to implement OpenOffice.org filters for foreign file formats.

Approaches

They are several ways to get information into or out of OpenOffice.org: You can

• link against the application core
• use the document API
• use the XML file format

Each method has unique advantages and disadvantages, that are summarized briefly:

Using the core data structure and linking against the application core is the traditional way to implement filters in OpenOffice.org. The advantages of this method are efficiency and direct access to the document. However, the core implementation provides an implementation centric view of the applications. Additionally, there are a number of technical disadvantages. Every change in the core data structures or objects must be followed by corresponding changes in code that uses them. Consequently, filters need to be recompiled to match the binary layout of the application core objects. While these are manageable, albeit cumbersome, for closed source applications, this method is expected to create a maintenance nightmare if application and filters are developed separately as is customary in open source applications. Simultaneous delivery of a new application build and the corresponding filters developed by third parties looks challenging.

Using the OpenOffice.org API based on UNO is more advantageous, since it solves the technical problems indicated in the above paragraph. The idea is to read data from a file on loading and build up a document using the OpenOffice.org API, and to iterate over a document model and write the corresponding data to a file on storing. The UNO component technology insulates the filter from binary layout, and other compiler and version dependent issues. Additionally, the API is expected to be more stable than the core interfaces, and provides an abstraction from the core applications. In fact, the example filter implementation of this section makes use of this strategy and is based on the OpenOffice.org API.

The third is to import and export documents using the XML-based file format. UNO-based XML import and export components feature all of the advantages of the previous method, but additionally provide the filter implementer with a clean, structured, and fully documented view of the document. A significant difficulty in conversion between formats is the conceptual mapping from the one format to the other. From OpenOffice.org 1.1.0 there are XML filter components that carry out the mapping at runtime, so that filter implementers can read from XML streams when exporting and write to XML streams when importing.

The following section describes the second method using the UNO-based API. Further details on the third method, based on the generic XML format are found in the xml project of OpenOffice.org under http://xml.openoffice.org/filter/. The third method to create XML based filters is described afterwards.