Über Oxygen-Frameworks und ediarum-Spezifika
Das grundsätzliche Vorgehen für die Konfiguration via sogenannter "Frameworks" finden Sie in der Oxygen-Dokumentation. Ediarum stellt für diese Konfiguration einige Standardbausteine bereit.
Framework-Komponenten
- Vorlagen für neue Dokumente, sodass die Editor:innen die XML-Struktur nicht "von null" alleine aufbauen müssen (XML-Template)
- Lesefreundliches Layout der XML-Inhalte im "Autor"-Tab, d.h. eine "What-you-see-is-what-you-get"-Schreiboberfläche, sodass die Editor:innen nicht direkt in XML schreiben müssen und ihre Textarbeiten übersichtlich und publikationsnah überprüfen können.
- Buttons und Aktionen in der Werkzeugleiste, sodass die Editor:innen XML-Elemente und Attributwerte per Klick und in Eingabefeldern einfügen können, ohne die benötigten XML-Elemente kennen zu müssen
- ggf. Transformationsszenarien, die verschiedene Publikations-Layouts zur Verfügung stellen, z.B. für Korrekturdurchläufe
Konfigurationskomponenten
Im Hintergrund besteht das Framework aus einer Sammlung von Dateien. Einige Aspekte der Konfiguration nehmen Sie direkt in den Dateien vor, für andere benutzen Sie das Dokumenttypen-Fenster.
Komponente | Beschreibung | Speicherung | Änderung |
---|---|---|---|
Was können Sie konfigurieren? | Welche Art von Komponenten werden verwendet? | Wo speichert Oxygen XML Author Ihre Konfigurationen? | In welchem Dateiformat speichert Oxygen XML Author Ihre Konfigurationen? |
Schema | XML-Schema (Strukturvorgaben) | RNG-Datei | Die RNG-Datei bearbeiten |
Template | Vorlage für neue XML-Dokumente | XML-Datei | Die XML-Datei bearbeiten |
GUI-Funktionalitäten | GUI-Elemente und -Funktionalitäten, die Oxygen XML Author dann im Autor-Modus bereitstellt | FRAMEWORK-Datei | Im Autor Tab des Dokumenttypen Fensters: , Framework auswählen |
Layout | Das Layout, welches die Nutzeroberfläche in Oxygen definiert. Dazu gehören u.a. die Anordnung der Fenster oder der Aufbau der Werkzeugleiste. | LAYOUT-Datei | Unter Fenster kann im Abschnitt "Layout" das Layout geladen, exportiert oder zurückgesetzt werden. |
ediarum-Spezifika für die Konfiguration per Framework
Ableitungsstruktur: ediarum.BASE.edit arbeitet mit dem Datenmodell des DTA-Basisformats (Subset von TEI-XML) und erweitert dieses an einigen Punkten. Für Ihr Editionsprojekt erweitern Sie wiederum das Datenmodell von ediarum.BASE.edit. Das Datenmodell für Ihr Editionsprojekt enthält also am Ende unterschiedlich generische Anteile, die voneinander abgeleitet sind: DTA-Basisformat > ediarum.BASE.edit > projektspezifische Schema-Anteile. Entsprechend dieser Ableitungsstruktur beim Datenmodell sind auch die Frameworks voneinander abgeleitet.
Dateinamen und Ordnerstrukturen: Für die Benennung und den Ablageort der Konfigurationsdateien folgt ediarum eigenen Konventionen, unter anderem, um eine einfache gebündelte Auslieferung eines Frameworks zu ermöglichen. Orientieren Sie sich an Struktur und Inhalten des ediarum.BASE.edit Ordners.
Oxygen-"Operationen": Die GUI-Funktionalitäten bestehen im Kern aus sogenannten"Operationen", d.h. Befehls-Bausteinen, aus denen Sie eine eigene Funktionalität zusammensetzen und mithilfe von Parametern auf Ihre Edition anpassen können. Dabei gibt es Operationen, die der Oxygen XML Author mitliefert, und solche, die eigens für ediarum programmiert und bereitgestellt wurden. Die Datei ediarum.jar enthält die ediarum-spezifischen Operationen, die Sie benutzen können.
Oxygen-"Editorvariablen": Die von Oxygen XML Author und von ediarum bereitgestellten Operationen und einige andere Konfigurationskomponenten sollen einfach und vielfältig wiederverwendbar sein. Deshalb sind, wo immer kontextspezifische Angaben nötig sind, anstatt konkreter Werte Platzhalter (Variablen) eingesetzt, z.B. für Projektname, Datei-, Ordner- und URL-Pfade. Die Werte dieser sogenannten Editor-Variablen sind einmal an zentraler Stelle definiert. Für Ihre eigene editionsspezifische Konfiguration müssen Sie die Werte für projektspezifische Editor-Variablen eintragen und gegebenenfalls zusätzliche, eigene Editor-Variablen erstellen, z.B. für zusätzliche Registerarten. Es empfiehlt sich, dabei die Namenskonventionen der bestehenden Editorvariablen konsistent weiter zu führen.