CIB doXiview - Integration

Über dieses Dokument

Dieses Dokument ist an Entwickler gerichtet, welche CIB doXiview als Komponente in ihre eigene Webapplikation integrieren.

In einfachen Anwendungsfällen kann CIB doXiview durch Referenzierung per URL ohne Einsatz von JavaScript integriert werden.

In weiterführenden Anwendungsfällen kann die integrierende Anwendung mit CIB doXiview kommunizieren. Diese Kommunikation erfolgt mithilfe von JavaScript-Funktionen unter Verwendung des Frameworks CIB iwc (Abkürzung für inter-window communication).

Die Verwendung dieser Schnittstelle ist Inhalt dieses Dokuments.

Für das Verständnis werden Grundlagenkenntnisse über HTML und JavaScript vorausgesetzt.

Beispielanwendungen und Testoberfläche

Die in diesem Dokument beschriebenen Funktionen lassen sich auch praktisch an Beispielen nachvollziehen. In der CIB doXiview Demoversion sind Beispiele von sehr einfachen HTML-Seiten enthalten, welche als minimale integrierende Beispielanwendungen dienen.

Zusätzlich ist in der Demoversion die Webapplikation CIB doXiview Test UI enthalten, mit welcher verschiedene Parameter komfortabel in einer Benutzeroberfläche eingegeben werden können. Sie können hier die Wirkung verschiedener Parameter zunächst testen, ohne dafür selbst Code schreiben zu müssen. Die generelle Verwendung dieser Testoberfläche ist in der Dokumentation KurzanleitungCibDoXiviewDemo.pdf beschrieben, welche zusammen mit der Demoversion ausgeliefert wird.

Möglichkeiten der Clientseitigen Integration von CIB doxiView

Es gibt prinzipiell 3 Möglichkeiten, wie CIB doXiview in einem Web-Browser geöffnet werden kann:

1. Aufruf von CIB doXiview durch Eingabe einer URL in die Adresszeile des Web-Browsers
2. Integration von CIB doXiview in eine andere Webapplikation über eine URL
3. Integration von CIB doXiview in eine andere Webapplikation über eine URL und CIB iwc

Diese Möglichkeiten werden im Folgenden kurz skizziert.

Aufruf von CIB doXiview durch Eingabe einer URL in der Adress-Zeile des Web-Browsers

CIB doXiview ist eine Webapplikation, welche im einfachsten Fall direkt über die Eingabe einer geeigneten URL in der Browser-Adresszeile geladen und angezeigt werden kann. In diesem Fall gibt der Benutzer direkt als Teil der URL ein, welches Dokument von CIB doXiview unmittelbar angezeigt wird. Die Anzeige nimmt anschließend vollständig einen Browser-Tab ein.

Beispiele:

1. Aufruf von CIB doXiview und Anzeige eines spezifizierten Dokuments
   Durch Eingabe der folgenden URL in der Adresszeile des Browsers wird CIB doXiview geöffnet und zeigt das Dokument example.pdf an:
   

   http://myserver/webview/?rsp=false&iwc_mode=standalone&urlField=http://myotherserver/example.pdf&ext=pdf

2. Aufruf von CIB doXiview ohne Dokument mit einem Upload-Button
   Durch Eingabe der nächsten URL in der Adresszeile des Browsers wird CIB doXiview zunächst ohne ein Dokument geöffnet. Der Benutzer kann anschließend per Schaltfläche in der CIB doXiview Toolbar ein Dokument aus dem lokalen Dateisystem auswählen und in CIB doXiview hochladen und anzeigen.
   

   http://myserver/webview/?rsp=false&uistyle=cib&iwc_mode=standalone&ui=upload

Starten Sie die Demoversion von CIB doXiview und geben die folgende URL im Web-Browser ein:

Aufruf von CIB doXiview über eine URL aus einer anderen Webapplikation

In den meisten Fällen soll CIB doXiview jedoch aus folgenden Gründen in eine andere Webapplikation, d.h. eine andere HTML-Seite, eingebettet werden:

1. Die einbettende Webapplikation bestimmt über Aufrufparameter, welches Dokument CIB doXiview anzeigen soll.
2. Die CIB doXiview-Oberfläche soll optisch in der Seite der einbettenden Webapplikation integriert werden, d.h. in einem <iframe> HTML-Tag. Die weiter oben genannten Beispiel-URLs können in dem Fall unverändert als Wert für das src-Attribut eingesetzt werden.

Die folgende Datei simple-iframe.html aus der CIB doXiview Demoversion integriert CIB doXiview mittels <iframe>-Tag. Diese kann dort aufgerufen werden wie folgt:

Alternativ könnte mit einem Anchor Tag <a> und dem href-Attribut CIB doXiview in einem neuen Browser-Tab geöffnet werden.

Die einbettende Webapplikation kann CIB doXiview auf diese Weise parametrisiert aufrufen, hat allerdings ab diesem Zeitpunkt keine Möglichkeit mehr, mit CIB doXiview innerhalb des Webbrowsers zu kommunizieren.

Integration von CIB doXiview über CIB iwc

Für die folgenden Anwendungsfälle wird eine engere Kopplung zwischen der einbettenden Webapplikation und CIB doXiview benötigt:

• Integration von eigenen Schaltflächen in die Toolbar von CIB doXiview und anschließende Reaktion, wenn der Benutzer diese anklickt
• Anzeigen von eigenen Hinweistexten an den Benutzer
• Sperren und Entsperren der Benutzeroberfläche von CIB doXiview
• Drucken in Originalqualität über einen Dienst außerhalb des Webbrowsers
• Anbindung von CIB doXiview an ein Archivsystem
• Editieren von Freitextbereichen in RTF-Dokumenten
• Ausfüllen von Unterschriftenfeldern

In diesen Fällen wird CIB doXiview nicht nur initial von der einbettenden Webanwendung aufgerufen, sondern kommuniziert auch anschließend mit ihr.

Zunächst wird wie im vorherigen Abschnitt Aufruf von CIB doXiview über eine URL aus einer anderen Webapplikation
beschrieben, CIB doXiview wieder mit einem <iframe> HTML-Tag in  die einbettende Anwendung integriert. Die Verwendung eines <iframe> wird bei dieser Integrationsart nun zwingend vorausgesetzt.

Im Unterschied zu Aufruf von CIB doXiview über eine URL aus einer anderen Webapplikation
wird hier als URL des iframe src-Attributes nur eine Basis-URL auf CIB doXiview angegeben:

<iframe src="http://myserver/webview/index.jsp?iwc_mode=internal"/>

Diese Basis-URL enthält nur den Parameter

iwc_mode=internal

Damit wird CIB doXiview signalisiert, dass weitere Parameter auf anderem Wege, nämlich mittels JavaScript-Funktionen übermittelt werden.

Das folgende Kapitel Kommunikation über CIB iwc erläutert die Integration über CIB iwc im Detail.

Kommunikation über CIB iwc

CIB iwc

CIB iwc (Abkürzung für inter-window communication) ist ein in JavaScript implementiertes Kommunikationsframework, welches es zwei Webanwendungen erlaubt, Clientseitig innerhalb des Web-Browsers miteinander zu kommunizieren.

Das Framework sorgt dafür, dass beide Anwendungen auch dann miteinander kommunizieren dürfen, wenn sie aus unterschiedlichen Domains stammen. Dies wird normalerweise aus Sicherheitsgründen von Web-Browsern unterbunden (Same Origin Policy). Im Umfeld großer Unternehmen ist es jedoch üblich, dass Anwendungen aus verschiedenen Domains stammen, etwa a.mycompany.com und b.mycompany.com.

CIB iwc basiert im Kern auf der HTML5-Funktion window.postMessage und wird in Form von JavaScript-Dateien von den beteiligten Anwendungen geladen.

Während zwei Anwendungen bei der direkten Verwendung von window.postMessage lediglich Strings austauschen können, ermöglicht CIB iwc eine Kommunikation auf höherer Ebene mittels JavaScript-Funktionsaufrufen.

Master und Slave

Damit zwei Webapplikationen über das CIB iwc Framework kommunizieren können, muss die eine Anwendung per HTML iframe-Tag in die andere Anwendung eingebettet werden.

Die einbettende Anwendung wird in diesem Zusammenhang Master oder Integrator genannt, die eingebettete Anwendung wird Slave genannt. Typischerweise erscheint aus Benutzersicht der Slave als Rechteck innerhalb des Masters. Der Master entscheidet darüber, wann und wie der Slave geladen wird.

Wenn CIB doXiview in Ihre Anwendung eingebettet wird, dann ist Ihre Anwendung in dieser Beziehung der Master und CIB doXiview ist der Slave.

Die folgende Abbildung veranschaulicht das:

Laden der CIB iwc JavaScript Ressourcen

Damit eine Kommunikation zwischen Master und Slave aufgebaut werden kann, müssen beide Webanwendungen als Voraussetzung zunächst das in Form von JavaScript Code vorliegende CIB iwc Frameworks laden.

Beispielsweise kann der CIB iwc Code von Ihrer Webseite aus der CIB doXiview Anwendung geladen werden wie folgt:

Prinzipiell ist dieser Ort beliebig. Sie können diese JavaScript-Ressource deshalb auch in Ihrer eigenen Anwendung als Kopie vorhalten und in Ihrem HTML Code mit einem relativen Pfad einbinden:

Wenn das CIB iwc Framework von vielen Anwendungen benutzt wird,  kann mehrfaches Laden der gleichen JavaScript-Datei in den Browser vermieden werden, wenn diese anwendungsübergreifend mit derselben URL referenziert wird:

Der Webbrowser hat so die Möglichkeit, diese Ressource zu cachen. CIB doXiview kann entsprechend konfiguriert werden, um CIB iwc ebenfalls von diesem zentralen Ort zu laden.

Im einfachsten Fall braucht nur das CIB iwc Framework selbst in Form der Datei cib.iwc.1.0.0.min.js geladen werden. Diese enthält für alle Anwendungen allgemein verwendbare Funktionen, beispielsweise zur Übergabe von Startparametern.

Zusätzlich werden anwendungsspezifische Funktionen in separaten JavaScript-Dateien bereitgestellt, welche auf dieselbe Weise eingebunden werden. Für die Kommunikation mit CIB doXiview ist dies die Datei iwc-interfaces-min.js.

Schließlich verwendet CIB iwc intern die JavaScript Bibliothek jQuery, welche deshalb ebenfalls von allen Kommunikationspartnern eingebunden werden muss.

Insgesamt werden also die folgenden drei JavaScript-Ressourcen für die Kommunikation Ihrer Anwendung mit CIB doXiview benötigt:

Soll eine Vielzahl von Anwendungen über CIB iwc kommunizieren, lässt sich das Laden der JavaScript-Ressourcen optimieren. Dies wird in Kapitel Optimierung zum laden der JavaScript-Ressourcen separat beschrieben.

Aufbau der Kommunikation Über CIB iwc

Nachdem der Master den CIB iwc JavaScript Code geladen hat, kann er den Slave laden und die Kommunikation zu diesem aufbauen. Anschließend sind Master und Slave in der Lage, mittels Funktionsaufrufen zu kommunizieren.

Der Aufbau der Kommunikation findet in folgenden Schritten statt:

1. CIB iwc laden: Laden der benötigten JavaScript-Ressourcen durch den Master
2. Initialisierung: Der Master initialisiert CIB iwc
3. Registrierung der Master-Funktionen: Der Master registriert in CIB iwc seine Funktionen, welche später vom Slave aus aufrufbar sein sollen
4. Laden des Slave: Der Master lädt über CIB iwc den Slave in dem gewünschten iframe mittels Aufruf der iwc-Funktion openUrlInFrame(iframe-id, url)
5. Registrierung Slave: Der JavaScript Code des geladenen Slave wird vom Browser ausgeführt und registriert in CIB iwc seine vom Master aufrufbaren Funktionen
6. Handshake zwischen Master und Slave: Der Slave ruft die Methode init(initCallback) an dem Master auf.
7. Benachrichtigung Slave über Handshake-Ergebnis: Wenn der Master die Initialisierung erfolgreich beendet hat, wird die success-Methode aus dem initCallback des Slaves aufgerufen. Wenn die Initialisierung nicht erfolgreich war, wird die failure-Methode aufgerufen.

Nach einem erfolgreichen Handshake ist die Kommunikation etabliert:

• Der Slave kann die vom Master bereitgestellten Funktionen aufrufen.
• Der Master kann die vom Slave bereitgestellten Funktionen aufrufen.

Für die Integration von CIB doXiview müssen Sie in Ihrer Master-Anwendung die Schritte 1. bis 4. implementieren. Dies wird im folgenden Abschnitt am Beispiel erläutert.

Die Schritte 5. bis 7. werden komplett von CIB iwc und CIB doXiview durchgeführt.

Beispiel: Laden von CIB doXiview und Übergabe der Startparameter via CIB iwc

Der im vorherigen Punkt beschriebene Ablauf soll an einem Minimalbeispiel anschaulich dargestellt werden. Dazu erzeugen wir eine integrierende Anwendung, die CIB doXiview in einem iframe öffnet und die Startparameter via CIB iwc übermittelt.

Der Beispielcode besteht aus den folgenden Abschnitten:

1. CIB iwc laden
2. Initialisierung
3. Registrieren der Master-Funktionen
4. Laden des Slave

Hinweis: Der folgende Beispielcode ist auch in der Demoversion von CIB doXiview enthalten und lässt sich dort aufrufen mit:

Hinweis: Das Öffnen von CIB doXiview und die Übergabe der Startparameter kann bequem mit der Testoberfläche nachvollzogen werden. Gehen Sie dazu wie folgt vor:

Startparameter iwc_mode

In unserem Beispiel wurde CIB doXiview wie folgt aufgerufen:

Als Ausnahme von der Regel, dass alle Startparameter mittels CIB iwc übertragen werden, ist hier ein einzelner Startparameter nach wie vor innerhalb der CIB doXiview URL definiert: iwc_mode=internal. Dieser Startparameter ist als Teil der URL vorgesehen, um CIB doXiview mitzuteilen, ob überhaupt eine Kommunikation mit einem Master etabliert werden soll.
Die folgenden Werte für diesen Startparameter sind möglich:

Master und Slave Interfaces

Die zur Kommunikation mit CIB doXiview zur Verfügung stehenden JavaScript-Funktionen sind nach Anwendungsfällen in mehrere Schnittstellen gruppiert.

Beispielsweise wurde im Abschnitt Aufbau der Kommunikation Über CIB iwc die Schnittstelle common verwendet, um die Startparameter zu übergeben:

Die folgende Tabelle gibt einen Überblick über die verwendbaren Schnittstellen:

Jede dieser Schnittstellen enthält zwei Arten von Funktionen:

Funktionen zum Registrieren Ihrer Master-Funktionen, welche von CIB doXiview aufgerufen werden können

Funktionen von CIB doXiview, welche von Ihrer Master-Anwendung aufgerufen werden können

In Kapitel die Kommunikationsschnittstellen werden alle Kommunikationsinterfaces mit den darin definierten Methoden im Detail beschrieben.

Die Result Callback-Struktur

Funktionen aus den Kommunikationsschnittstellen können entweder einen definierten Rückgabewert oder keinen Rückgabewert haben.

Wird eine Funktion aufgerufen, die keinen Rückgabewert definiert, bekommt die aufrufende Anwendung nach dem Aufruf keinerlei Rückmeldung mehr in irgendeiner Form.

Wenn dagegen eine Funktion mit einem Rückgabewert definiert ist, muss der Aufrufer seinerseits zwei Funktionen namens success und failure definieren, welche im Erfolgsfall und im Fehlerfall mit einem jeweils passenden Rückgabewert aufgerufen werden. Diese beiden Funktionen werden zu einem Objekt zusammengefasst übergeben, welches im folgenden Result Callback genannt wird. Das Result Callback lässt sich am einfachsten als JavaScript Objekt-Literal definieren wie folgt:

Der im Fehlerfall an failure übergebene Parameter error ist stets wie folgt aufgebaut:

Die Struktur des im Erfolgsfall an success übergebenen Parameters params hängt jeweils von der aufgerufenen Funktion ab und ist der Dokumentation der Funktion zu entnehmen.

Beispielsweise liefert die Funktion getViewStateInfo der Kommunikationsschnittstelle doXiview im Erfolgsfall laut Dokumentation die folgende Struktur als Parameter params:

{
    currentBundleDocumentID: the current bundle document id,
    currentDocumentID: the current document id,
    currentDocumentPageCount: the page count for the current document,
    currentPageNumber: the current page number
}

Das folgende Code-Beispiel fasst zusammen, wie Sie mit dieser Funktion in Ihrer Master-Anwendung die Nummer der aktuell in CIB doXiview angezeigten Dokumentseite und die Anzahl der Seiten abfragen können:

Die obige Funktion displayPageNumber() könnte z.B. vom Benutzer Ihrer Anwendung durch einen wie folgt definierten Button ausgelöst werden:

Die Kommunikationsschnittstellen

Erklärung zur SchnittstellenBeschreibung

Die Verwendung einer Funktion zur Kommunikation setzt voraus, dass

• der eine Kommunikationsteilnehmer die Funktion für den anderen bereitstellt, und
• der andere Kommunikationsteilnehmer die Funktion aufruft.

Um die jeweilige Seite der Kommunikation deutlich zu machen, besteht eine Namenskonvention.

Der Bereitsteller einer Funktion namens someFunction ruft zu diesem Zweck eine Funktion auf, die per Konvention registerSomeFunctionCallback genannt wird.

Der Aufrufer kann diese Funktion anschließend aufrufen, per Konvention unter dem Namen someFunction.

Die Benennung dieser Funktionen hängt also nicht von der generellen Rolle einer Anwendung als Master oder Slave ab, sondern von der Richtung der Kommunikation bezogen auf eine einzelne Funktion.

Beispiel: Es gibt eine Funktion, welche CIB doXiview in Richtung seines Masters aufruft, um Startparameter zu erhalten.

Da in diesem Fall der Master die Funktion bereitzustellen hat, ruft er zu diesem Zweck die in seiner Schnittstelle CibMasterCommonFunctions  definierte Funktion mit Namen registerStartParametersCallback auf. Als Parameter übergibt er die vom Slave aufrufbare Funktion:

var getStartParameters = function(…
registerStartParameterCallback(getStartParameters)

Als Aufrufer dieser Funktion ist der Slave vorgesehen. Er ruft dazu die in seiner Schnittstelle CibSlaveCommonFunctions vorhandene Funktion getStartParameters auf:

var resultCallback = { success: function…
getStartParameters(resultCallback)

In den Funktionsbeschreibungen in diesem Kapitel ist im untersten Abschnitt Registration definiert, ob entweder der Master oder der Slave die definierte Funktion registrieren muss. Die jeweils andere Seite kann die Funktion mit dem Namen aufrufen, welcher links oben unter Function genannt ist.

Jede Funktionsbeschreibung ist aus Sicht der aufrufenden Seite formuliert.

Ihre Anwendung, in welche CIB doXiview integriert wird, ist immer der Master.

getStartParameters

callback: ResultCallback

JSON

var startParameters = {
          context : {login context},
          webview : {
               // doxiview specific start parameters
          },
          webedit : {
               // webEdit specific start parameters
          }
  }

master.common.registerStartParameterCallback(callback: FunctionCallback);

Beispiel-Implementierung aus Sicht Master (integrierende Anwendung):

master.common.registerStartParameterCallback(function() {
var startParameters = {
                "webview": {
                         "uistyle":"cib",
                         "ui":"upload",
                }
        };
        return startParameters;
});

Das common Interface

Allgemein

Das Kommunikations-Interface common definiert generelle Funktionen, welche nicht CIB doXiview-spezifisch sind, sondern auch in anderen per CIB iwc integrierbaren Anwendungen zum Einsatz kommen können.

Es ist aus Sicht des Masters in Form des Objekts CibCommonMasterFunctions verfügbar.

Dieses wird wie folgt erzeugt:

getStartParameters

Diese Funktion wurde bereits als Beispiel erläutert. Mittels dieser Funktion erfragt CIB doXiview von seinem Integrator die zu verwenden Startparameter.

getStartParameters

callback: ResultCallback

JSON

var startParameters = {
          context : {login context},
          webview : {
               // doXiview specific start parameters
          },
          webedit : {
              // webEdit specific start parameters
          }
  }

master.common.registerStartParameterCallback(callback: FunctionCallback);

Beispiel-Implementierung aus Sicht Master (integrierende Anwendung):

master.common.registerStartParameterCallback(function() {
        var startParameters = {
               "webview": {
                       "uistyle":"cib",
                       "ui":"upload",
               }
        };
        return startParameters;
});

Hinweis: In der CIB doXiview Testoberfläche können verschiedene voreingestellte Startparameter-Belegungen aus einer Liste ausgewählt werden.

Zudem können mit den Schaltflächen „Add Entry“ und „Add Text Entry“ weitere Startparameter einzeln gesetzt werden:

terminate

Wenn CIB doXiview beendet werden soll, kann es notwendig sein, dass abschließend Daten über die beendete Sitzung an den Master übermittelt werden oder dieser auf das Beenden der Dokumentbetrachtung reagieren soll. Dazu ruft CIB doXiview die Funktion terminate auf.

terminate

code: int
data: JSON
errorDescription: String

void

master.common.registerTerminateCallback(callback: FunctionCallback);

fireDataDirty

In CIB doXiview können Änderungen vorliegen, die der Benutzer noch nicht gespeichert hat. Beispiele hierfür sind noch nicht gespeicherte Annotationen oder ein geändertes RTF-Freitextfeld. Damit der Master darauf reagieren kann, ruft CIB doXiview die Funktion fireDataDirty auf.

fireDataDirty

isDataDirty: boolean
message: String
messageId: int

void

master.common.registerFireDataDirtyCallback(callback: FunctionCallback);

lock, unlock

Es kann erforderlich sein, die gesamte CIB doXiview Benutzeroberfläche zu sperren um sie gegen unbefugte Eingaben zu schützen. Beispielsweise durch eine explizite Sperranforderung des Benutzers oder wenn der Benutzer längere Zeit inaktiv war. Ein späteres Entsperren der Oberfläche ist ebenfalls möglich. Beides wird durch den Master veranlasst.

lock

N/A

void

slave.common.registerLockCallback(callback: FunctionCallback);

unlock

N/A

void

slave.common.registerUnlockCallback(callback: FunctionCallback);

logout

Wird in der Master-Anwendung ein Logout des Benutzers durchgeführt, sollte CIB doXiview darüber informiert werden, z. B. um einen eventuell geöffneten Freitext-Editor schließen.

Slave Interface:

logout

N/A

void

slave.common.registerLogoutCallback(callback:FunctionCallback);

resize

In CIB doXiview ist es möglich, die Größe der Anwendung anzupassen. Dies wird durch einen Aufruf der Funktion resize realisiert.

Slave Interface:

resize

width: int
height: int

void

slave.common.registerResizeCallback(callback: FunctionCallback);

showMessage

Der Master kann die Funktion showMessage aufrufen, um in CIB doXiview Nachrichten für den Benutzer anzuzeigen. Diese werden über dem Dokument eingeblendet und nach einer gewissen Zeit automatisch ausgeblendet.

showMessage

messageText: String

void

slave.common.registerShowMessageCallback(callback: FunctionCallback);

Das webview Interface

Allgemein

Das Interface webview definiert allgemeine Funktionen zur Kommunikation mit CIB doXiview. Zudem sind hier Funktionen enthalten, welche beim Editieren von RTF verwendet werden.

Es ist aus Sicht des Masters in Form des Objekts CibWebviewMasterFunctions verfügbar.

finishLoading

CIB doXiview informiert den Master durch Aufruf der Funktion finishLoading, wenn der Ladevorgang eines Dokuments abgeschlossen wurde. Daraufhin kann der Master weitere Aktionen auslösen, z. B. zum Freischalten von eigenen Toolbar-Schaltflächen.

finishLoading

successful: boolean

void

boolean: successful:

master.webview.registerFinishLoadingCallback(callback:
  FunctionCallback);

Beispiel-Implementierung aus Sicht des Masters:

master.webview.registerFinishLoadingCallback (function(params) {
      // work with “params.successful” which can be true or false
      // returning something is not needed since return type is “void” 
});

Hinweis: In der Testoberfläche kann die Benachrichtigung durch CIB doXiview über  finishLoading beobachtet werden: Sobald CIB doXiview ein  Dokument geladen hat, reagiert die Testoberfläche darauf, indem sie den Aufruf in der Konsole ausgibt.

getViewStateInfo

Der Master kann durch Aufruf von getViewStateInfo CIB doXiview nach dem aktuellen Zustand der Anzeige befragen, beispielsweise welche Seite momentan ausgewählt ist.

getViewStateInfo

callback: JSON

JSON

JSON: callback:

{
          currentBundleDocumentID: the current bundle document id,
          currentDocumentID: the current document id,
          currentDocumentPageCount: the page count for the current document,
          currentPageNumber: the current page number
  }

slave.webview.registerGetViewStateInfoCallback(callback:FunctionCallback)

Beispiel-Implementierung aus Sicht des Masters:

master.webview.getViewStateInfo ({   
    success: function(params) {       
        // work with params.currentBundleDocumentID       
        // work with params.currentDocumentID           
        // work with params.currentDocumentPageCount             
        // work with params.currentPageNumber         
    },   
    failure: function(error) {       
        // log error or something            
    }
});

Hinweis: In der Testoberfläche kann dieser Aufruf mit der Schaltfläche „RuntimeManipulation/Third Party Functions/Get View State“ ausgelöst werden. Das Ergebnis des Aufrufs wird in der Konsole der Testoberfläche ausgegeben.

finishEditing

Diese Funktion spielt lediglich für den Anwendungsfall „Editieren von Freitextpassagen in einem RTF-Dokument“ mittels CIB webEdit eine Rolle.

CIB doXiview kann seinen Master darüber informieren, ob ein Editiervorgang erfolgreich abgeschlossen wurde. Zu diesem Zweck wird die sogenannte editSessionId an den Master kommuniziert, sowie eine Liste elementList der modifizierten Freitextbereiche. Falls kein Text verändert wurde, ist diese Liste leer.

Der Master kann daraufhin beispielsweise die editierten Freitextbereiche weiterverarbeiten. Für weitergehende Informationen hierzu kontaktieren Sie bitte Ihren Ansprechpartner bei CIB.

finishEditing

editSessionId: String
elementList: Array

void

master.webview.registerFinishEditingCallback(callback:FunctionCallback)

Hinweis: In der Testoberfläche kann in der Konsolenausgabe die Benachrichtigung durch CIB doXiview über finishEditing einfach nachvollzogen werden:

1. Öffnen Sie CIB doXiview in dem Modus webEdit
2. Editieren Sie eine Freitextpassage
3. Beenden Sie das Editieren durch Speichern oder Abbrechen

setSnippetEditingAllowed

Diese Funktion spielt lediglich für den Anwendungsfall „Editieren von Freitextpassagen in einem RTF-Dokument“ mittels CIB webEdit eine Rolle.

Der Master kann CIB doXiview zur Laufzeit mitteilen, ob Freitextpassagen editierbar sein sollen oder nicht. CIB doXiview reagiert auf diesen Aufruf damit, dass Freitextpassagen als editierbar, bzw. als nicht editierbar dargestellt werden.

setSnippetEditingAllowed

snippetEditingAllowed: boolean

void

boolean: snippetEditingAllowed:

slave.webview.registerFinishEditingCallback(callback:FunctionCallback);

Hinweis: In der Testoberfläche kann diese Funktion wie folgt aufgerufen werden:

1. Öffnen Sie CIB doXiview im Modus webEdit.
2. Haken Sie auf dem Reiter Runtime Manipulation die Checkbox enable editing an und aus. Dies verändert unmittelbar die Darstellung der Freitextbereiche.

Darstellung der Freitextbereiche bei der Einstellung true:

Darstellung der Freitextbereiche bei der Einstellung false:

cancelEditing

Diese Funktion spielt lediglich für den Anwendungsfall „Editieren von Freitextpassagen in einem RTF-Dokument“ mittels CIB webEdit eine Rolle.

Sie ermöglicht dem Master den aktuellen Editiervorgang abzubrechen, sofern ein solcher gestartet wurde. CIB doXiview schließt daraufhin den Editor. Dabei kann angegeben werden, ob die aktuellen Änderungen gespeichert werden sollen. Dies kann die integrierende Master-Anwendung zum Beispiel vorher über einen dort angezeigten Dialog erfragen.

cancelEditing

saveChanges: boolean

void

boolean: saveChanges:

slave.webview.registerCancelEditingCallback(callback:FunctionCallback);

Hinweis: In der Testoberfläche kann diese Funktion wie folgt ausgelöst werden:

1. Öffnen Sie CIB doXiview im Modus webEdit
2. Öffnen Sie per Doppelklick auf einen Editierbereich den Texteditor, und geben Sie Text ein.
3. Klicken Sie auf dem Reiter Runtime Manipulation auf die Schaltfläche Cancel Editing. Wenn die Option save changes angehakt ist, dann werden Ihre Textänderungen übernommen, sonst nicht.

showNotification

Der Master kann die Funktion showNotification aufrufen, um in CIB doXiview Nachrichten für den Benutzer anzuzeigen. Diese werden über dem Dokument eingeblendet und nach einer gewissen Zeit automatisch ausgeblendet. Zudem kann die Art der Nachricht (Info, Warnung, Fehler, etc.) angegeben werden.

showMessage

messageText: String
messageType: String

void

slave.common.registerShowNotificationCallback(callback: FunctionCallback);

onDocumentVersionUpdated

CIB doXiview informiert den Master durch Aufruf der Funktion onDocumentVersionUpdated, wenn das Dokument verändert wurde. Der Master kann daraufhin die neue Dokument-Version weiterverarbeiten.

Damit der Integrator über die Änderung des Dokuments informiert wird, muss der Start-Parameter propagateDocumentVersionUpdates auf true gesetzt werden.

onDocumentVersionUpdated

webstoreId: String
location: String

void

master.webview.registerOnDocumentVersionUpdatedCallback(callback: FunctionCallback);

Beispiel-Implementierung aus Sicht des Masters:

master.webview.registerOnDocumentVersionUpdatedCallback (function(params) {
      // work with “params.webstoreId”
      // work with “params.location” which is an url
      // returning something is not needed since return type is “void” 
});

applicationStarted

CIB doXiview informiert den Master durch Aufruf der Funktion applicationStarted, wenn die Anwendung vollständig geladen wurde. Dieser Aufruf bedeutet nicht, dass das Dokument geladen wurde. Es signalisiert lediglich die vollständige Verfügbarkeit der Anwendung. Der Integrator kann daraufhin mit doXiview interagieren und beispielsweise ein Dokument mit openDocument öffnen.

applicationStarted

keine

void

master.webview.registerApplicationStartedCallback(callback: FunctionCallback);

Beispiel-Implementierung aus Sicht des Masters:

master.webview.registerApplicationStartedCallback (function() {
      // returning something is not needed since return type is “void” 
});

openDocument

Der Master kann die Funktion openDocument aufrufen, um ein neues Dokument zu öffnen, ohne doXiview komplett neu laden zu müssen. Die Start-Parameter werden dabei neu geladen. Abgesehen von Parametern, welche das Aussehen von doXiview steuern, können alle Startparameter individuell für das zu öffnende Dokument angepasst werden.

openDocument

-

void

slave.common.registerOpenDocumentCallback(callback: FunctionCallback);

Beispiel-Implementierung aus Sicht des Masters:

master.webview.openDocument();

Das archive Interface

Allgemein

CIB doXiview kann über die Server-seitige Schnittstelle CIB Archive API an ein Archivsystem angebunden werden, um von dort Dokumente zu laden und anzuzeigen.

Das Interface archive definiert Funktionen, welche in diesem Fall Client-seitig zur Kommunikation benötigt werden.

Es ist aus Sicht des Masters in Form des Objekts CibArchiveMasterFunctions verfügbar.

Für weitere Informationen zur Anbindung von CIB doXiview an ein Archivsystem sei auf die separate Dokumentation CIB doXiview - Archivmodus verwiesen.

getNextArchiveObjectId

Diese Funktion wird lediglich für die Anzeige von Archivdokumenten benötigt.

Über eine entsprechende Schaltfläche in CIB doXiview kann der Benutzer zum nächsten anzuzeigenden Archivobjekt navigieren. Welches das nächste Archivobjekt ist, erfragt CIB doXiview daraufhin mit der Funktion getNextArchiveObjectId bei seinem Master. Typischerweise hat die Master-Anwendung aktuell eine Menge von Archivobjekten aufgelistet, z.B. ein Suchergebnis.

getNextArchiveObjectId

archiveObjectId: String

JSON

String: archiveObjectId:

var res = {
  archiveObjectId: "the next archive object id"
  archiveDocumentIndex: "the index of the next archive object"
  first: "whether or not it is the first archive object"
  last: "whether or not it is the last archive object"
  }

master.archive.registerGetNextArchiveObjectIdCallback(callback: FunctionCallback);

getPreviousArchiveObjectId

Diese Funktion wird lediglich für die Anzeige von Archivdokumenten benötigt.

Analog zu getNextArchiveObjectId fragt CIB doXiview seinen Master nach der vorherigen Archivobjekt-Id, wenn der Benutzer eine entsprechende Schaltfläche in CIB doXiview betätigt.

getPreviousArchiveObjectId

archiveObjectId: String

String

String: archiveObjectId:

var res = {
  archiveObjectId: "the next archive object id"
  archiveDocumentIndex: "the index of the next archive object"
  first: "whether or not it is the first archive object"
  last: "whether or not it is the last archive object"
  }

master.archive.registerGetPreviousArchiveObjectIdCallback(callback: FunctionCallback);

beforeArchiveLoad

Diese Funktion wird lediglich für die Anzeige von Archivdokumenten benötigt.

CIB doXiview erfragt mit der Funktion beforeArchiveLoad weitere Informationen zu dem zu ladenden Archivobjekt, bevor das Archivobjekt serverseitig geladen wird. 

beforeArchiveLoad

archiveObjectId: String
archiveDocumentIndex: int
metaData: String

JSON

master.archive.registerBeforeArchiveLoadCallback(callback: FunctionCallback);

afterArchiveLoad

Diese Funktion wird lediglich für die Anzeige von Archivdokumenten benötigt.

Wenn das Archivobjekt serverseitig geladen wurde, ruft CIB doXiview den Master mit der Funktion afterArchiveLoad auf.

afterArchiveLoad

archiveObjectId: String
archiveDocumentIndex: int
metaData: String

JSON

master.archive.registerAfterArchiveLoadCallback(callback: FunctionCallback);

Das print Interface

Allgemein

Im Unternehmensumfeld kann CIB doXiview zusammen mit einem auf dem Arbeitsplatzrechner befindlichen Gerätedienst-Server zusammenarbeiten. Dieser kann Dienste außerhalb der Browser-Sandbox bereitstellen, um direkt über das Betriebssystem mit Geräten wie z. B. Druckern kommunizieren zu können. Auf diese Weise kann ein in CIB doXiview angezeigtes Dokument in Originalqualität gedruckt werden.

Das Interface print enthält die daran beteiligten Funktionen.

Es ist aus Sicht des Masters in Form des Objekts CibPrintMasterFunctions verfügbar.

getPrinterList

Diese Funktion wird lediglich für das Drucken von Dokumenten über einen lokalen Gerätedienst benötigt.

Wenn über einen lokalen Gerätedienst gedruckt werden soll und der Benutzer in CIB doXiview den entsprechenden Druckdialog öffnet, wird ihm eine Liste der zur Verfügung stehenden Drucker angezeigt.

Diese Liste erfragt CIB doXiview über die Funktion getPrinterList von der Master-Anwendung. Das Besorgen dieser Liste vom lokalen Gerätedienst ist Aufgabe des Masters.

Zur Ermittlung der Drucker übergibt CIB doXiview einen Kontext als Parameter. Dieser Kontext wurde beim Start von CIB doXiview über den Startparameter webview.context hinterlegt und von dem Viewer durchgereicht.

getPrinterList

printContext: String
callback: ResultCallback

JSON

String: printContext:

{
          printers :
          [{
                 name: "printer 1",
               displayName: "PrinterName (location)",
                deviceServiceIP: "10.8.110.1",
                status: "Im Leerlauf",
                comment: "Kommentar a",
                location: "Raum A1 Gang 2",
                type: "printer type"
        }, {
                name: "Microsoft XPS Document Writer",
                displayName: "Microsoft XPS Document Writer (Raum A1 Gang 2)",
                deviceServiceIP: "127.0.0.1",
                status: "Im Leerlauf",
                comment: "Kommentar b",
                location: "Raum A1 Gang 2",
                type: "Microsoft XPS Document Writer"
        }],
        lastSelectedPrinterIndex:
  1 
}

master.print.registerGetPrinterListCallback(callback: FunctionCallback);

startPrint

Diese Funktion wird lediglich für das Drucken von Dokumenten über einen lokalen Gerätedienst benötigt.

CIB doXiview informiert über startPrint die Master-Anwendung, wenn der Benutzer in dem Druckdialog mit der Schaltfläche Ok betätigt und der Druckvorgang gestartet werden soll.

Der Master delegiert daraufhin den Druckvorgang an den Master.

startPrint

data: JSON
callback: JSON

void

{
          printer: "Microsoft XPS Document Writer",
          deviceServiceIP: "127.0.0.1",
          undIds: ["1231435543645647567567", "234234324234234234"],
          context: "the print context, e.g. “ARC” for “archive”",
          options: "print options such as number of copies”
          jobName: "1234 - Test Formular"
  }

master.print.registerPrintCallback(callback: FunctionCallback);

openPrintDialog

Diese Funktion wird lediglich für das Drucken von Dokumenten über einen lokalen Gerätedienst benötigt.

CIB doXiview bietet die Funktion openPrintDialog an, mit welcher der Master das Öffnen des Druckdialogs in CIB doXiview veranlassen kann.

openPrintDialog

N/A

void

slave.print.registerOpenPrintDialogCallback(callback: FunctionCallback);

Hinweis: In der Testoberfläche kann dieser Aufruf wie folgt ausgelöst werden:

1. Öffnen Sie CIB doXiview im Modus DVS
2. Klicken Sie in dem Bereich Basic Parameters die Schaltfläche Add Entry und fügen Sie externalPrint und true als Startparameterwerte ein.
3. Klicken Sie auf dem Reiter Runtime Manipulation auf die Schaltfläche Print.

Das sign Interface

Allgemein

Das Interface sign enthält Funktionen für das Hinzufügen von elektronischen  Unterschriften zu PDF-Dokumenten.

Es ist aus Sicht des Masters in Form des Objekts CibSignMasterFunctions verfügbar.

CIB doXiview ist in der Lage, Felder für elektronische Unterschriften in PDF Dokumenten optisch hervorzuheben und diese für den Benutzer per Doppelklick auswählbar zu machen.

Der eigentliche Vorgang des Signierens wird von der Master-Anwendung übernommen und die neue Dokument-Version anschließend in der bestehenden Sitzung erneut angezeigt.

Als Voraussetzung sind zum Freischalten der signaturrelevanten Funktionalität die folgenden Startparameter an CIB doXiview zu übergeben:

var startParameters = {
webview: {
               digSigEnabled: Freischalten der Signatur-Funktionalität
               uploadSignContent: Wenn Jview-Dateien (von CIB webDesk) unterschrieben werden 
                        sollen.
   }
}

signatureInfo

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt.

Wenn ein Dokument geladen wurde, teilt CIB doXiview  dem Master über diese Funktion alle im Dokument vorhandenen Unterschriftenfelder mit.

signatureInfo

signatureList: JSON

void

        var signatureList = [
                  signature: signature information,
                  ...
          ]

        var signature = {
                  name: The unique field name
                  info: Additional information to the signature
                  isRequired: Whether or not the signature is required
                  isSigned: Whether or not the signature was already signed
                  signatureLocation: the information to identify the signature in
                             the loaded document
          }

        var signatureLocation = {
                  receiverCopyName: entry exists only if receiver copy name exists
                  pageNumber: the page Number
                  topLeftX: the top left x coordinate of the signatures bounding box
                  topLeftY: the top left y coordinate of the signatures bounding box
                  width: the width of the signatures bounding box
                  height: the height of the signatures bounding box
          }

master.sign.registerSignatureInfoCallback(callback: FunctionCallback);

Hinweis: In der Testoberfläche kann die Benachrichtigung durch CIB doXiview wie folgt beobachtet werden:

1. Öffnen Sie CIB doXiview im Modus Sign (Pdf)
2. In der Konsole können Sie die übergebenen Informationen einsehen, nachdem das Dokument geladen wurde:

signatureSelected

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt.

Wenn der Benutzer einen Doppelklick auf einem Unterschriftenfeld ausführt, soll dieses mit einer Unterschrift gefüllt werden. Da das eigentliche Signieren die Aufgabe des Masters ist, wird dieser mittels signatureSelected darüber informiert, dass und in welchem Feld unterschrieben werden soll. Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt.

signatureSelected

signature: JSON

void

       var signature = {
                  name: The unique field name
                  signatureLocation: the information to identify the signature in
                                     the loaded document

        var signatureLocation = {
                  receiverCopyName: entry exists only if receiver copy name exists
                  pageNumber: the page Number
                  topLeftX: the top left x coordinate of the signatures bounding box
                  topLeftY: the top left y coordinate of the signatures bounding box
                  width: the width of the signatures bounding box
                  height: the height of the signatures bounding box
          }

master.sign.registerSignatureSelectedCallback(callback: FunctionCallback);

Hinweis: In der Testoberfläche kann dieser Aufruf wie folgt nachvollzogen werden:

In der Konsole können Sie die übergebenen Informationen einsehen:

documentToSign

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt - auch nur dann, wenn es sich bei dem Dokument um eine .jview-Datei handelt, d.h. das Dokument aus CIB webDesk / CIB darkDesk stammt.

Im Falle von .jview-Dateien findet ein zusätzlicher Funktionsaufruf von CIB doXiview an den Master statt. CIB doXiview legt das Dokument in der Komponente webstore ab und informiert den Master, unter welcher webstoreId es dort aufzufinden ist. Dieser kann es dann bei Bedarf aus dem webstore herunterladen und signieren.

documentToSign

webstoreId: String

void

master.sign.registerDocumentToSignCallback(callback: FunctionCallback);

Hinweis: In der Testoberfläche kann dieser Aufruf wie folgt nachvollzogen werden:

1. Öffnen Sie CIB doXiview im Modus Sign (Jview)
2. In der Konsole wird angezeigt, unter welcher webstoreId CIB doXiview das Dokument abgelegt hat.

loadSignedDocument

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt.

Nachdem eine neue Signatur auf dem Dokument aufgebracht und die neue Dokument-Version vom  Master im webstore abgelegt wurde, teilt der Master CIB doXiview mittels loadSignedDocument mit, unter welcher webstoreId CIB doXiview die neue Version des Dokumentes laden soll.

loadSignedDocument

webstoreId: String 
signatureLocation: JSON

Void

       var signatureLocation = {
                  pageNumber: the page Number
                  topLeftX: the top left x coordinate of the signatures bounding box
                  topLeftY: the top left y coordinate of the signatures bounding box
                  width: the width of the signatures bounding box
                  height: the height of the signatures bounding box
          }                

slave.sign.registerLoadSignedDocumentCallback(callback: FunctionCallback);

UpdateSignedDocument

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt - auch nur dann, wenn es sich bei dem Dokument um eine .jview-Datei handelt, d.h. das Dokument aus CIB webDesk / CIB darkDesk stammt.

Analog zu der loadSignedDocument Funktion kann im Falle für .jview-Dateien die neue Dokumentversion mit dem folgenden Aufruf propagiert werden.

updateSignedDocument

webstoreId: String 
signatureLocation: JSON

Void

        var signatureLocation = {
                  pageNumber: the page Number
                  topLeftX: the top left x coordinate of the signatures bounding box
                  topLeftY: the top left y coordinate of the signatures bounding box
                  width: the width of the signatures bounding box
                  height: the height of the signatures bounding box
          }

slave.sign.registerUpdateSignedDocumentCallback(callback: FunctionCallback);

setSignatureEditingAllowed

Diese Funktion wird lediglich für das Hinzufügen von elektronischen Unterschriften zu einem PDF Dokument benötigt.

Der Master kann zur Laufzeit über die Funktion setSignatureEditingAllowed bestimmen, ob das Dokument generell unterschreibbar sein soll.

setSignatureEditingAllowed

signatureEditingAllowed: boolean

Void

slave.sign.registerSetSignureEditingAllowedCallback(callback: FunctionCallback);

Das toolbar Interface

Allgemein

Das Interface toolbar dient der Manipulation von Toolbar-Schaltflächen.

Es ist aus Sicht des Masters in Form des Objekts CibMasterToolbarFunctions verfügbar.

Es ist möglich, dass der Master eigene Schaltflächen in die CIB doXiview Toolbar einbettet. CIB doXiview kann die Master-Anwendung darüber informieren, wenn der Benutzer auf eine solche Schaltfläche geklickt hat. Darüber hinaus ist es möglich, für alle Schaltflächen der Haupt-Toolbar die folgenden Zustände zu beeinflussen: aktiviert, deaktiviert, sichtbar, unsichtbar.

Bei der Integration von Schaltflächen in die CIB doXiview Toolbar ist wie folgt vorzugehen.

1. Das Icon der Schaltfläche wird fest in der css-Definition von CIB doXiview hinterlegt und wird nicht über das Client-seitige Interface übergeben. Es wird hier nur über eine css-Id referenziert. Wird ein individuelles Icon benötigt, muss dies also schon beim Deployment von CIB doXiview hinterlegt werden.
2. In den Startparametern müssen die Schaltflächen übergeben werden, die in der CIB doXiview Toolbar integriert werden sollen.
3. Es ist möglich, nach Auslösen von Benutzerereignissen die Schaltflächen über definierte Schnittstellen zu verändern, z. B. deaktivieren.

Definition von Schaltflächen in den Startparametern:

CIB doXiview fragt die hinzuzufügenden Schaltflächen in den Startparametern ab, damit der Master nicht prüfen muss, wann CIB doXiview vollständig initialisiert ist. CIB doXiview fügt dann auf Basis der Startparametereinträge die Schaltflächen eigenständig hinzu.

Aufbau des Startparameters für die Schaltflächendefinitionen:

toolbar: {
    buttons: [{           
        buttonId: String: the buttons id,           
        buttonLabel: String: the buttons label (may be displayed in menus),           
        cssId: String: the buttons css id,           
        tooltip: String: the buttons tooltip,           
        isEnabled: boolean: whether or not the button should be enabled,
        isVisible: boolean: whether or not the button should be visible,           
        group: String: the buttons group,           
        groupIndex: <optional> int: group position if it has to be created,           
        index: int: the buttons index within its group,           
        buttonGroup: <optional> String: the buttons composite group,     
    }, {            
        ...second button definition     
    }]
}

toolbarButtonPressed

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Wenn der Master eigene Schaltflächen in die CIB doXiview Toolbar integriert hat, wird er über die Funktion toolbarButtonPressed darüber informiert, welche Schaltfläche vom Benutzer betätigt wurde.

toolbarButtonPressed

buttonId: String

void

master.toolbar.registerButtonPressedCallback(callback: FunctionCallback);

Hinweis: In der Testoberfläche kann dieser Aufruf von CIB doXiview an den Master nachvollzogen werden:

1. Selektieren Sie den Modus Sign (Pdf)
2. In dem Bereich Toolbar Configuration wählen Sie Sign aus.
3. Öffnen Sie CIB doXiview
4. Die ersten zwei Schaltflächen in der Toolbar sind nun die vom Master eingefügten Schaltflächen: 
5. Klicken Sie auf eine der beiden Schaltflächen.
6. In der Browser-Konsole erscheint der JavaScript-Aufruf:

2015-01-19 14:22:59,237 [INFO ] OUTER: toolbarButtonPressed(params: {"buttonId":"sign-button"})

updateButton

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Schaltflächen können mit der Funktion updateButton unter Angabe der buttonId zur Laufzeit verändert werden. Dabei können eingestellt werden:

• Css-Id
• Tooltip
• Aktivierungszustand
• Sichtbarkeit

updateButton

params: JSON

void

        {
                  buttonId: the external id of the button,
                  cssId: the CSS id of the button (for appearance),
                  tooltip: the tooltip of the button,
                  isEnabled: whether or not the button should be enabled,
                  isVisible: whether or not the button should be visible
          }

slave.toolbar.registerToolbarCallback(toolbar.updateButton=function(params));

Hinweis: In der Testoberfläche kann der Aufruf vom Master an CIB doXiview nachvollzogen werden:

1. Selektieren Sie den Modus Sign (Pdf)
2. In dem Bereich Toolbar Configuration wählen Sie Sign aus.
3. Öffnen Sie CIB doXiview
4. In dem Reiter Runtime Manipulation unter Toolbar control können Sie nun mit dem Button Id Wert sign-button die Eigenschaften für diese Schaltfläche etwa wie folgt eingeben. Klicken Sie anschließend auf Test.

setEnabled

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Soll nur der Aktivierungszustand einer Schaltfläche verändert werden, kann der Master die Funktion setEnabled aufrufen.

setEnabled

buttonId: String
enable: boolean

void

slave.toolbar.registerToolbarCallback(toolbar.setEnabled=function(params));

setVisible

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Soll nur der Sichtbarkeitszustand einer Schaltfläche verändert werden, kann der Master die Funktion setVisible aufrufen.

setVisible

buttonId: String
isVisible: boolean

void

slave.toolbar.registerToolbarCallback(toolbar.setVisible=function(params));

setTooltip

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Soll nur der Tooltip verändert werden, kann der Master die Funktion setTooltip aufrufen.

setTooltip

buttonId: String
tooltip: String

void

slave.toolbar.registerToolbarCallback(toolbar.setTooltip=function(params));

triggerButton

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Mit der Funktion triggerButton kann der Master den Klick auf eine Schaltfläche auslösen.

triggerButton

buttonId: String

void

slave.toolbar.registerToolbarCallback(toolbar.triggerButton=function(params));

Hinweis: In der Testoberfläche kann dieser Aufruf durch den Master nachvollzogen werden:

1. Selektieren Sie den Modus Sign (Pdf)
2. In dem Bereich Toolbar Configuration wählen Sie Sign aus.
3. Öffnen Sie CIB doXiview
4. Wählen Sie auf dem Reiter Runtime manipulation unter Toolbar control in der Drop-Down-Liste Trigger aus.
5.  Belegen Sie Button Id mit sign-button und klicken Sie auf Test

setToggleButtonState

Diese Funktion wird lediglich für eine Anpassung der Toolbar benötigt.

Mit dieser Funktion können sogenannte Toggle-Buttons beeinflusst werden. Dies sind Buttons mit den Zuständen gedrückt und nicht gedrückt.

setToggleButtonState

buttonId: String
pressed: boolean

void

slave.toolbar.registerToolbarCallback(toolbar.toggleButton=function(params));

Optimierung zum laden der JavaScript-Ressourcen

In diesem Kapitel werden Details zu einem optimierten Deployment der benötigten JavaScript-Ressourcen erläutert.

In unserem Beispiel-Code wurde CIB iwc mit dem folgenden Script-Tag geladen:

<script type="text/javascript" src="lib-js/cib.iwc.1.0.0.min.js"></script>

Das vom Master genutzte Kommunikationsinterface wurde zusätzlich mit diesem Script-Tag geladen:

<script type="text/javascript" src="lib-js/cib.iwc.master.webview.js"></script>

Beide Ressourcen liegen hier innerhalb der (Master-)Anwendung als Kopie vor. Das ist einfach zu handhaben und Sie können die JavaScript-Ressourcen mit einem konstanten, relativen src-Pfad adressieren, den Sie daher nicht konfigurierbar halten müssen.

Falls eine größere Zahl von Webapplikationen im Unternehmen über CIB iwc kommuniziert, ist es effizienter, diese Ressourcen insgesamt nur einmal vom Browser laden zu lassen, statt von jeder Anwendung in Kopie.

Dies lässt sich erreichen, indem alle Anwendungen diese Ressourcen über dieselbe URL laden, etwa

<script type="text/javascript" 
src="http://mycompany.com/lib-js/cib.iwc.1.0.0.min.js"></script>

CIB doXiview sollte ebenfalls solche geteilten JavaScript-Ressourcen laden. Es kann in CIB doXiview konfiguriert werden, welche JavaScript-Dateien in welchem iwc-Modus (internal, standalone, external) geladen werden sollen.

Per Voreinstellung werden alle benötigten JavaScript-Dateien (JQuery, CIB iwc sowie die dazugehörigen Kommunikationsschnittstellen) aus CIB doXiview selbst geladen. Sofern es nicht gewünscht ist, die JavaScript-Ressourcen zentral bereit zu stellen, besteht demnach auch keine Notwendigkeit diese Konfiguration zu ändern.

Ansonsten geschieht dies durch Überschreiben der existierenden Standardeinstellungen, welche in der Datei default-config.properties definiert sind. Das Überschreiben der dort vorhandenen Einstellungen wird stets in der Datei environment-config.properties vorgenommen, welche sich im selben Verzeichnis befindet. Die Datei default-config.properties sollte nicht modifiziert werden.

Folgende Standardeinstellungen können überschrieben werden:

# Define jquery java script location
jquery=webview_gwt/jquery/jquery-1.11.1.min.js
 
# Define iwc core framework
iwc=webview_gwt/iwc/cib.iwc.1.0.0.min.js
 
# Define communicational adapters for iwc framework
iwc.interface=webview_gwt/iwc/iwc-interfaces-min.js
 
# Define iwc_mode java scripts and the default mode if no start parameter is used.
(iwc_mode=external needs to be defined in environment-config.properties)
iwc.mode.standalone=${jquery}
iwc.mode.internal=${jquery},${iwc},${iwc.interface}
iwc.mode.default=INTERNAL 

Die Konfiguration beschreibt die Quellen für JQuery, CIB iwc und allen Kommunikationsinterfaces für CIB iwc. Anschließend werden für die verschiedenen iwc.mode-Möglichkeiten die JavaScript-Dateien definiert, die im jeweiligen Modus von CIB doXiview geladen werden sollen.

In welchem Modus CIB doXiview arbeitet, wird per Startparameter an CIB doXiview übergeben.