Eclipse RCP in der Redaktion von tagesschau.de

Eclipse bei der Tagesschau

Torsten Witte
Die Dokumentsuche im DeskClient

Die Suche ist eine zentrale Komponente im Sophora DeskClient, über die Redakteure jene Dokumente heraussuchen, die sie bearbeiten oder in anderen Dokumenten referenzieren möchten. Ein Redakteur muss also anhand der Anzeige im Suchergebnis erkennen, welches der gefundenen Dokumente für ihn relevant ist. Dazu müssen sowohl Statusinformationen als auch redaktionelle Inhalte dargestellt werden, z. B. das Dokumenttyp- und Status-Icon, die Überschrift, das Thumbnail, das letzte Bearbeitungsdatum, der letzter Bearbeiter und gegebenenfalls weitere Inhalte, abhängig vom Dokumenttyp. Die Lösung über eine einfache SWT-Liste oder -Tabelle wäre zu unübersichtlich und auch optisch nicht ansprechend geworden. Daher wurde in dem DeskClient-Projekt ein ExtendedListViewer entwickelt, der sich von dem JFace StructuredViewer ableitet. Die Listenelemente des ExtendedListViewer, d. h. die Domainobjekte, die der zugehörige IContentProvider liefert, werden in Form von beliebigen SWT Controls dargestellt, die über einen entsprechenden IControlProvider erzeugt werden. Der IControlProvider ist an dem ExtendedListViewer analog zu seinem IContentProvider zu setzen. Die erzeugten Controls werden vom ExtendedListViewer verwaltet. Wenn Listenelemente aktualisiert werden sollen, werden die betroffenen Controls aus dem internen Cache entfernt und beim IControlProvider neu angefragt. Auf diese Weise werden die einzelnen Suchergebnisse in der Suche aktualisiert, wenn z. B. ein (anderer) Redakteur die Überschrift einer Meldung ändert und das Dokument speichert, während es in der Suche angezeigt wird. Ebenso kann die Darstellung der Suchergebnisse über den IControlProvider ausgetauscht werden. Abbildung 2 zeigt die verschiedenen Darstellungsmodi in der Suche: Einzeilig, Kompakt und Galerie.

Abb. 2: Abb. 2: „ExtendedListViewer“ mit verschiedenen Anzeigenmodi (Vergrößern)

Der Dokumenteditor

Das Editorkonzept der RCP gestaltet die Entwicklung von Editoren einfach. Für jedes beliebige Domainobjekt kann ein entsprechender EditorPart mit jeweiligem IEditorInput entwickelt werden. Über MultiPageEditorPart können sogar mehrere Editoren als ein Editor mit mehreren Reitern zusammengefasst werden. Für den Sophora DeskClient musste eine generische Editorlösung entwickelt werden, da es für die einzelnen fachlichen Dokumenttypen (wie Meldungen, Bilder, Übersichtsseiten, Downloads usw.) keinesfalls jeweils eine eigenständige, feste Editorimplementierung geben sollte. Das hätte zum einen den Entwicklungs- und Wartungsaufwand erhöht, zum anderen hätte bei jedem neu hinzukommenden (projektspezifischen) Dokumenttyp ein weiterer Editor entwickelt werden müssen. Dies hätte wiederum die Erstellung eines neuen Releases und ein Rollout der neuen Version zur Folge.

Aus diesem Grund ist der Sophora-Dokumenteditor so generisch gebaut, dass er für beliebige Dokumenttypen verwendet werden kann. Der Administrator kann Dokumenttypen definieren und pro Dokumenttyp konfigurieren, welche Felder es gibt, welche Beschriftung die einzelnen Felder haben, welcher Eingabefeldtyp jeweils verwendet wird (Textfeld, Auswahlfeld usw.), wo das Feld erscheint, ob es ein Pflichtfeld ist u. v. m. Diese Konfiguration wird beim Öffnen des Dokumenteditors anhand des jeweiligen DocumentEditorInput ermittelt, ausgelesen und daraus die Editoroberfläche zusammengestellt. Beim Speichern des Dokuments wird in der doSave()-Methode eine Validierung der einzelnen Eingabefelder durchgeführt und gegebenenfalls eine Fehlermeldung angezeigt. Um dieselbe Flexibilität bei der Menge der zur Verfügung stehenden Eingabefeldtypen zu erreichen, wird das vorhandene Plug-in-Framework genutzt. Grundsätzlich wird im DeskClient zwischen zwei Arten von Eingabefeldtypen unterschieden:

  • IFormField: Eingabefeldtypen, die auf einem primitiven Datentyp arbeiten, z. B. Textfeld, Datumsfeld, Auswahlfeld etc.
  • IEditorComponent: Eingabefeldtypen, die auf einem komplexen Datenmodell arbeiten, z. B. Bildeditorkomponente, Copytext-Editor-Komponente (siehe unten) etc.

Für beide Arten gibt es je einen Extension Point, über den jeder Eingabefeldtyp deklariert wird. Weitere Eingabefeldtypen können über Plug-ins hinzugefügt werden. So sind z. B. das Eingabefeld für Geokoordinaten (auf Basis von Bing Maps) zur geographischen Zuordnung von Nachrichtenmeldungen sowie die Verwaltung und Bearbeitung von Teletextseiten solche Produkterweiterungen, die als DeskClient-Plug-ins umgesetzt wurden. Listing 1 zeigt exemplarisch die Deklarationen des einfachen Textfeldes und der Copytext-Editor-Komponente in der plugin.xml.

Listing 1
Die Copytext-Editorkomponente

Die größte Herausforderung bei der Entwicklung des DeskClients war die Umsetzung einer Editorkomponente zur Erfassung des Fließtextes (von z. B. Nachrichtenmeldungen). Diese Inhalte müssen strukturiert erfasst werden und bestehen aus verschiedenartigen Absätzen, Überschriften, einfachen Textformatierungen (wie fett, kursiv und Listen), Textlinks, Absatzbildern, barrierefreien Tabellen, Textauszeichnungen (wie Zitat, Sprache und Abkürzungen) sowie Absatzboxen mit Referenzen auf weiterführende Dokumente. Eine Rechtschreibprüfung darf natürlich auch nicht fehlen. Abbildung 3 zeigt den Aufbau der Copytext-Editorkomponente, dem so genannten Copytext-Editor.

Abb. 3: Copytext-EditorAbb. 3: Copytext-Editor (Vergrößern)

Der Copytext-Editor ist kein WYSIWYG-Editor. Er dient lediglich der strukturierten Erfassung der Textinhalte, die in einem entsprechenden Modell aus Absätzen abgelegt und wieder ausgelesen werden können. Wie die Inhalte später auf einer Webseite (oder einem anderen Ausspielkanal) angezeigt werden, ist bei der Implementierung der jeweiligen Ausspielung zu entscheiden.

Geschrieben von
Torsten Witte
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.