Die freie und offene Büro-Software
Apache OpenOffice 4.0.1 ist verfügbar!

FAQ über die OpenOffice.org-API

Diese FAQs werden zur Zeit überarbeitet. Den aktuellen Stand können Sie im Projekt-Wiki einsehen.
Sollten Sie hier nicht fündig geworden sein, so suchen Sie bitte im Dokumentationsportal und/oder im OOo-Wiki nach einer Lösung.

Welche Programmiersprachen unterstützt die OpenOffice-API?

OpenOffice stattet die API mit UNO (Universal Network Objects) aus. Im Moment gibt es Sprachanbindungen an Java und C++. Du kannst auch deine eigene Sprachanbindung realisieren, und ehrlich gesagt suchen wir noch dringend einen Freiwilligen, der eine Anbindung an C realisiert.

Zusätzlich erlaubt UNO die Kontrolle durch Skriptsprachen und Skriptumgebungen (etwa Debugger). Aktuell kann StarBASIC (syntaxkompatibel mit VBA) die API aufrufen. Außerdem gibt es einen Prototypen für Python.

Was ist der Unterschied zwischen UNO IDL und CORBA?

UNO IDL basiert auf CORBA IDL, aber unterstützt zusätzlich
  •   die Erbschaft für Ausnahmen und Strukturen,

  •   zugewiesene Werte für Aufzählungen,

  •   einen neuen stereotypen "service"
    (kombiniert Schnittstellen und Eigenschaften).

Und es unterstützt im Moment nicht:
  •   Reihen als definierte Typen

  •   Unionen

Welchen Umfang hat die API Spezifikation?

Die API besteht aus etwa 2000 Dateien, wobei jede einen Typ spezifiziert. Ein Typ kann in diesem Zusammenhang ein Service sein, eine Schnittstelle, eine Struktur, eine Ausnahme, eine konstante Gruppe oder eine Aufzählung. Alles zusammen sind dies etwa 6 MB Daten.

Wie ist die API dokumentiert?

So etwas wie eine Dokumentation gibt es innerhalb der IDL Dateien. Die Syntax der Dokumentation basiert auf JavaDoc und verfügt über einige Erweiterungen, um Identifizierer zu markieren. Wir sind gerade dabei, einen neuen Generator für diese Syntax zu entwickeln, der HTML Dokumente direkt aus den IDLs generiert.

Zusätzlich gibt es ein "programmer's manual", das die grundlegenden Konzepte erklärt, einige UML Diagramme der Komponentenstruktur zeigt und eine Menge dokumentierter Beispiele der API Benutzung beinhaltet. Dieses Handbuch benutzt zur Zeit StarBASIC als Sprache für die Beispiele, aber wir arbeiten auch an einer Java Version.

Welchen Umfang hat die API Implementation?

Es ist fast unmöglich, das zu sagen. Derzeit sind die meisten Teile der API nur lose mit der Kern-API verbunden. Nur neuere Komponenten unterstützen die API direkt. Deshalb macht es wenig Sinn, herauszufinden, wieviel Code die API implementiert. Je nach Perspektive können wir möglicherweise sagen: Das ganze OpenOffice ist eine Umsetzung der API, gerade deshalb, weil mehr und mehr Merkmale die API anderer Komponenten nutzen.

Gibt es Dokumentationen oder Beispiele für Java Programmierer?

Im UDK Projekt findest du Dokumentationen über die Sprachanbindung an Java. Es gibt einige Java Beispiele in der StarOffice SDK, die recht hilfreich sein kann.

Warum gibt es in der OpenOffice-API einige Schnittstellen, die in keiner der OpenOffice-Komponenten auftauchen?

Die OpenOffice-API ist eigentlich mehr eine Spezifikation denn eine API einer existierenden Implementation. Es gibt einige Gründe dafür, warum es Schnittstellen ganz ohne Anbindung an die API gibt:
  1. es könnte eine optionale Schnittstelle innerhalb aller Dienste sein, die ihn nutzen können, aber keiner setzt sie auch wirklich um,
  2. es könnte eine Schnittstelle sein, die ein Konzept orthogonal macht, aber die Dimensionen, die es anspricht, werden im Moment nicht benötigt.
  3. es könnte Teil eines Entwurfes sein, der noch nicht umgesetzt wurde,
  4. sein Fehlen könnte auch einfach nur ein Bug sein.

Wie finde ich heraus, ob ich eine bestimmte Schnittstelle der OpenOffice-API benutzen kann?

Such nach einem Dienst, der diese Schnittstelle ausführt, dann such nach einer Komponente, die diesen Dienst unterstützt. Denk auch an optionale Schnittstellen (werden in der Ausführungs-Dokumentation des Dienstes erwähnt). Falls der Teil, den du nutzt, die Schnittstelle immer noch nicht unterstützt, handelt es sich um einen Fehler. Falls Letzteres zutrifft, berichte dem Entwickler dieser Komponente von dem Fehler. Falls es sich um einen Spezifizierungsfehler handelt, leitet er den Fehler an den Urheber der Spezifikation weiter.

Existieren Schnittstellen, um kombinierte Dokumente wie etwa Microsofts OLE zu bauen?

Innerhalb der StarOffice API existieren im Moment keine Schnittstellen zur Schaffung von verknüpften Dokumenten. Wir überlegen, das Bonobo Modell für diesen Zweck zu nutzen.

Wie geht ihr mit Konflikten in Bezug auf Konstruktionsfragen um?

Um es ganz klar zu sagen: Die API ist als eine Spezifikation gedacht, die ihr Hauptaugenmerk auf eine orthogonale Struktur sowie Wiederverwendbarkeit setzt. Andererseits haben wir versucht, Java so ähnlich zu sein wie möglich. Nutzwert von beiden Seiten, sowohl im Bereich der Umsetzung als auch der direkten Benutzung, ist ein weiterer wichtiger Punkt. Und hier müssen wir oft Kompromisse eingehen - manchmal einfach deshalb, weil es schon eine existierende Umsetzung gibt.

Falls es zu Konflikten kommt, setzen wir auf Konsens. Wir hören uns in Ruhe alle Argumente an und suchen nach neuen Argumenten anstatt hastig Entscheidungen zu treffen. Wir versuchen Lösungen zu finden, mit denen jeder gut leben kann.

Welche Rolle spielst du, Michael Hönnig?

Ich war der Chefarchitekt der StarOffice API, die nun zur OpenOffice API wird. Meine vorrangige Verantwortung lag darin, einen gemeinsamen Weg zu finden, Richtlinien für die IDLs zu erstellen und darauf zu achten, dass diese eingehalten wurden. Desweiteren sollte ich übertragbare Schnittstellen finden, eine einheitliche API-Infrastruktur erstellen und auf die Dokumentation achten.

Ich bin bereit, diese Aufgaben solange weiter zu führen, wie ich durch die Community darin unterstützt werde.

Apache Software Foundation

Copyright & License | Privacy | Website Feedback | Contact Us | Donate | Thanks

Apache, the Apache feather logo, and OpenOffice are trademarks of The Apache Software Foundation. OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.