Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 2 Nächste Version anzeigen »

ZusammenfassungSteuerung, ob server- oder clientseitig gerendert werden (über PredefinedAnnotationRenderStrategy.CLIENT und PredefinedAnnotationRenderStrategy.SERVER_SIDE_MASKING)
JWT VersionDie Anleitung wurde für jadice web toolkit Version 5.4.11.0 erstellt.

Status Quo

Annotationen werden im JWT grundsätzlich clientseitig gerendert. Es sei denn, die Annotationen sind mit den Berechtigungen DENY.CHANGE und DENY.REMOVE belegt. Dann werden sie grundsätzlich serverseitig gerendert.

Das große Aber

Anwendungsfälle, die dynamisch clientseitig Permissions auf Annotationen verändern, werden dadurch kompliziert und unperformant. Unperformant deshalb, weil die Berechtigungen synchron client- und serverseitig gesetzt werden müssen, und dadurch wiederholte Roundtrips zum Server erforderlich sind, 

  • um die Berechtigungen auch serverseitig umzuschalten und 
  • ein Neurendern der betroffenen Kacheln auf dem Server auszulösen.

Fall Nummer 1: DENY.SHOW

  • Der Benutzer soll zur Laufzeit einzelne, unveränderliche Annotationen ein- oder ausblenden können. 
  • Die bestehenden Annotationen sind mit DENY.CHANGE und DENY.REMOVE vorbelegt, da sie von anderen Benutzern erstellt wurden und nachträglich nicht mehr änderbar sind.
  • Prinzipiell lässt sich die Anforderung durch Zuordnung der Berechtigung DENY.SHOW/ALLOW.SHOW zur Annotation lösen.
  • Aber: Werden die Annotationen (so wie es bisher das Standard-Verhalten im JWT ist) serverseitig gerendert, so erfordert jede Änderung der Permission DENY.SHOW/ALLOW.SHOW an der Annotation eine ServerOperation, um deren neuen Zustand serverseitig bekannt zu machen und die mit DENY.SHOW belegten Annotationen vom serverseitigen Rendering auszuschließen.

Fall Nummer 2: DENY.CHANGE und DENY.REMOVE

  • Die Anwendung soll sich zwischen einem Ansichts- und Bearbeitungsmodus umschalten lassen.
  • Hierzu sollen die Bearbeitungsrechte auf allen Annotationen zur Laufzeit gewechselt werden können: von DENY.CHANGE && DENY.REMOVE zu ALLOW.CHANGE && ALLOW.REMOVE und umgekehrt.
  • Prinzipiell lässt sich die Anforderung durch Zuordnung der Berechtigungen auf den Annotationen lösen.
  • Aber: Werden die mit  DENY.CHANGE && DENY.REMOVE belegten Annotationen serverseitig gerendert  (so wie es bisher das Standard-Verhalten im JWT ist), erfordert jede Änderung der Permissions an der Annotation eine ServerOperation, um deren neuen Zustand serverseitig bekannt zu machen und die mit Annotationen ins serverseitige Rendering aufzunehmen bzw. vom serverseitigen Rendering auszuschließen.

Die Lösung

Wie schön wäre es doch, wenn der Integrator steuern könnte, ob Annotationen server- oder clientseitig gerendert werden sollen.

Der einzige Grund für das zwingende serverseitige Rendern von Annotationen, die mit DENY.CHANGE && DENY.REMOVE belegt sind, war bisher der folgende:

Unveränderliche Annotationen (also solche mit DENY.CHANGE && DENY.REMOVE) könnten dazu dienen, sensible Dokumentinhalte von unbefugten Anwendern zu verstecken.

Aber: die beiden neuen Anwendungsfälle benutzen die Permissions DENY.CHANGE && DENY.REMOVE auf den Annotationen gar nicht zum Maskieren, sondern lediglich zum Schutz vor Veränderung!

Mit JWT 5.4.11.0 stehen dem Integrator deshalb zwei vordefinierte {{AnnotationRenderStrategy}}s zur Verfügung:

  • eine, die das bisherige Verhalten abbildet (SERVER_SIDE_MASKING)
  • und eine Strategie, die ein neues Verhalten, nämlich ein vollständig clientseitiges Rendern der Annotationen ermöglicht (CLIENT) - unabhängig von den Permissions auf den Annotationen

Die Strategie wird aus der DocumentDataProvider-Implementierung wie folgt gesetzt:

PredefinedAnnotationRenderStrategy.CLIENT.applyToDocument(Document)

Die Strategie kann pro Dokument gesetzt werden - damit ist der Integrator flexibler.

Fall Nummer 1: DENY.SHOW - So geht's besser

Soweit, so gut. Über ein simples, clientseitiges Command lassen sich die Berechtigungen setzen und ein Neuzeichnen : 

private final AbstractPageViewCommand cmdHide = new AbstractPageViewCommand() {
@Override
protected void execute() {
AnnotationPageSegment annoSegment = (AnnotationPageSegment) getPageView().getCurrentPage().getPageSegment(
DocumentLayer.ANNOTATIONS);
    for (Annotation annotation : annoSegment.getAnnotations()) {
if (annotation instanceof TextAnnotation) {
clearAnnoShowPermissions(annotation);
annotation.getPermissions().getPermissions().add(IndividualAnnotationPermission.DENY.SHOW);
        // it is essential to set the modified flag here, in order to transport the permission
// change to the server and ensure that the annotations with DENY.SHOW will NOT be
// rendered when exporting the document as PDF
annotation.setModified();
}
}
   getPageView().repaint();
   ToolManager tm = leftViewer.getPageView().getToolManager();
ThumbnailTool thumbnailTool = tm.getTool(ThumbnailTool.class);
thumbnailTool.getThumbnailView().repaint();
}
};

(Warnung) Einen einzigen kleinen Fallstrick gibt es jedoch dabei: möchte man, dass die DENY.SHOW-Permission beim Ausdruck des Dokuments Anwendung findet (und somit die versteckten Annotationen auch im Ausdruck versteckt werden), so muss die Annotation als "modified" gekennzeichnet werden (siehe oben: annotation.setModified()). Dies kann nun umgekehrt zu Problemen beim Speichern der Annotationen per ServerOperation führen. Obwohl die Annotation eigentlich schon gespeichert war und nicht verändert wurde, ist sie nun wegen obigen Commands vom Client als "modified" markiert und wird in der ServerOperation an den Server übertragen.

(Glühbirne) Eine mögliche Lösung besteht darin, alle Annotation initial beim serverseitigen Laden aus dem Archiv mit einer User-Property zu versehen, die die Annotation als "archiviert" kennzeichnet und dieses Flag beim Speichern neuer Annotationen zu überprüfen.

Fall Nummer 2: DENY.CHANGE & DENY.REMOVE - Nichts einfacher als das

Ganz analog funktioniert das nun auch mit dem rein clientseitigen Umschalten der Änderungs- und Löschberechtigungen:

private final AbstractPageViewCommand cmdAllow = new AbstractPageViewCommand() {
@Override
protected void execute() {
    AnnotationPageSegment annoSegment = (AnnotationPageSegment) getPageView().getCurrentPage().getPageSegment(
DocumentLayer.ANNOTATIONS);
    for (Annotation annotation : annoSegment.getAnnotations()) {
clearAnnoChangeANDRemovePermissions(annotation);
annotation.getPermissions().getPermissions().add(IndividualAnnotationPermission.ALLOW.REMOVE);
annotation.getPermissions().getPermissions().add(IndividualAnnotationPermission.ALLOW.CHANGE);
}
   getPageView().repaint();
ThumbnailTool thumbnailTool = tm.getTool(ThumbnailTool.class);
thumbnailTool.getThumbnailView().repaint();
  }
};

Hier gibt es keine weiteren Fallstricke, die einem das Leben schwer machen.

  • Keine Stichwörter