Untergeordnete Seiten
  • Videos im jadice web toolkit
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Mit der Version 5.5.0.0 des jadice web toolkit wurde die Enterprise Demo um eine exemplarische Einbindung von Videos und Audios ergänzt. Die gesamte Logik zum Abspielen dieser Formate ist damit Teil des Democodes und nicht Bestandteil des Produktkerns. Dieser Artikel beschreibt die strategischen Hintergründe und beantwortet die Frage, weshalb Videos und Audios kein Kernbestandteil des jadice web toolkit sind. Außerdem zeigt er, wie sie trotzdem einfach integriert werden können.

Weshalb sind Videos/Audios kein fester Bestandteil des Produkts (und sollen es laut aktueller Planung auch nicht werden)?

Die unterstützten Dokumentenformate werden alle von der jadice document platform, welche auch die Basis des jadice web toolkits bildet, interpretiert, aufbereitet, gerendert und schlussendlich als PNG-Kachel an den Browser zur Anzeige geschickt. Die jadice document platform interpretiert jedoch keine Video-/Audio-Dateien (und wird dies auch in Zukunft nicht tun).

Wie funktioniert dann die Anzeige von Videos/Audios in der Demo?

In der Enterprise Demo wird ein eigener Viewer verwendet, um die Logik zwischen der Anzeige von Dokumenten und der Anzeige von Videos/Audios zu trennen. Diesem Viewer wird ein video- bzw audio-Tag hinzugefügt, welches in seinem src-Attribut eine URL enthält. Die URL zeigt dabei auf ein Servlet, das den Datenstrom des Videos bzw. Audios einliest und diesen an den Client schickt. Die eigentliche Anzeige des Videos übernimmt der Browser.

Könnte man nicht aber trotzdem das Video über einen DocumentDataProvider, eine Source und ein PageSegmentHandle laden, so wie Dokumente auch?

Nein. Das Source-/Handle-Prinzip bringt hier nur unnötige Roundtrips, ohne einen Mehrwert zu bieten.

Eine kurze Erklärung des Konzepts:

  • Der Client möchte das Dokument "Beispieldokument.pdf" laden, erstellt für dieses Dokument eine Source und schickt diese an den Server.
  • Der Server erhält die Source und lädt über den DocumentDataProvider das Dokument.
  • In der weiteren Verarbeitung auf dem Server werden dann PageSegmentHandles für jede Seite erstellt. Diese identifizieren jeweils genau eine Seite des Dokuments.
  • Zeitgleich wird die Struktur des Dokuments an den Client gesendet (die eigentlichen Inhalte des Dokuments liegen nur auf dem Server vor). Die Struktur umfasst:
    • Die Anzahl an Seiten
    • Größe der Seiten
    • Properties
    • Layer pro Seite (Dokument Layer, Annotation Layer)
    • Einige weitere Meta-Informationen
    • Und die erwähnten PageSegmentHandles
  • Wenn der Client nun eine Seite anzeigen möchte, schickt er das PageSegmentHandle mit einigen Renderinformationen an den Server. Dieser ermittelt aus dem PageSegmentHandle die zugehörige Seite und führt einen Rendervorgang für diese Seite durch. Das Ergebnis des Rendervorgangs wird als PNG-Datenstrom an den Client zurückgeschickt und vom Browser angezeigt.

Wie sähe dieser Mechanismus auf Videos übertragen aus?

  • Im Client würde eine Source für das Video erzeugt, welche angibt, von wo das Video geladen werden soll.
  • Serverseitig würde aus dieser Source ein einziges PageSegmentHandle für das Video erstellt, welches als Identifikator für das Video dienen würde. Das PageSegmentHandle würde an den Client geschickt werden.
  • Clientseitig würde ein video-Tag erzeugt, welches als src-Attribut das Handle in irgendeiner Form wieder zum Server sendet, wo ein Servlet dann den eigentlichen Video-Datenstrom bereithält.

In unserer Demo-Umsetzung reduzieren wir uns auf den dritten Schritt: Erzeugen einer URL, die das Video klar referenziert, welches dann von einem Servlet auf Serverseite bereitgestellt wird. Die ersten beiden Schritte stellen einen unnötigen Umweg dar.

Aber wie sieht denn jetzt eine mögliche Umsetzung aus?

Clientseite

Hier empfiehlt es sich, die Dokumentenanzeige komplett von der Video- bzw. Audio-Anzeige zu trennen. In der Regel gibt es einen Dokumentenanzeigebereich mit Toolbars etc., welcher im Kern einen über den com.levigo.jadice.web.client.ViewerBuilder erzeugten Viewer besitzt. Hier bietet es sich an, für die Wiedergabe von Video- bzw. Audioformaten den kompletten Viewer-Bereich auszutauschen. Hintergrund ist, dass Toolbarelemente, über die der Benutzer die Dokumentenanzeige beeinflussen kann, für Videos unpassend sind. Beispielsweise würde ein Button, über den eine Textsuche ausgelöst werden kann, den Benutzer bei der Betrachtung eines Videos vermutlich verwirren. Im Zweifelsfall kann natürlich auch nur der eigentliche Viewer ausgetauscht werden, wir raten lediglich davon ab, das Video in den Viewer einzuhängen.

In der Enterprise Demo wird dieser Teil durch den com.levigo.jadice.web.demo.enterprise.client.JadiceMediaViewer abgebildet.

Die eigentliche Ladelogik könnte dann in etwa so aussehen:

Videos in GWT Java
Videos in JavaScript

Serverseite

Auf Serverseite muss dann nur noch ein Servlet implementiert werden, das den Datenstrom bereitstellt. Diese Logik ist im Folgenden in drei Abschnitte geteilt, da über ein Servlet die Video Daten und über ein anderes die Audio Daten geladen werden. Da die Logik im Hintergrund in beiden Fällen die gleiche ist, bauen die beiden Servlets auf einer abstrakten Superklasse auf.

VideoServlet
AudioServlet
ResourceServlet

 

Eine kurze Übersicht dessen, was die Klasse ResourceServlet macht:

  • Der eigentliche InputStream wird geöffnet
  • Checken ob vom Client im HTTP Request der Range Header gesetzt wurde, über den lediglich ein Intervall des Video- bzw. Audiodatenstroms zum Download angefordert werden kann
    • Bei gesetztem Range Header die Range auswerten
      • Header für HTTP Response setzen
      • Den gegebenen Bereich des InputStreams in den OutputStream schreiben
    • Bei nicht gesetzten Range Header
      • Header für HTTP Response setzen
      • Den InputStreams in den OutputStream schreiben

 

 

5 von 78 Ergebnissen werden angezeigt