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?
- Was ist der Unterschied zwischen UNO IDL und CORBA?
- Welchen Umfang hat die API Spezifikation?
- Wie ist die API dokumentiert?
- Welchen Umfang hat die API Implementation?
- Gibt es Dokumentationen oder Beispiele für Java Programmierer?
- Warum gibt es in der OpenOffice-API einige Schnittstellen, die in keiner der OpenOffice-Komponenten auftauchen?
- Wie finde ich heraus, ob ich eine bestimmte Schnittstelle der OpenOffice-API benutzen kann?
- Existieren Schnittstellen, um kombinierte Dokumente wie etwa Microsofts OLE zu bauen?
- Wie geht ihr mit Konflikten in Bezug auf Konstruktionsfragen um?
- Welche Rolle spielst du, Michael Hönnig?
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
Und es unterstützt im Moment nicht:
|
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. |
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:
|
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. |