Untergeordnete Seiten
  • AnnotationRenderStrategy zur Steuerung des client-/serverseitigen Annotationsrendering im JWT
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

 

 

Gültig ab JWT Version 5.4.11.0

Diese Anleitung beschreibt, wie man mittels PredefinedAnnotationRenderStrategy.CLIENT und PredefinedAnnotationRenderStrategy.SERVER_SIDE_MASKING steuern kann, ob Annotationen server- oder clientseitig gerendert werden,

 

Status Quo

Annotationen werden im jadice web toolkit 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:

Icon

Unveränderliche Annotationen (also solche mit DENY.CHANGE && DENY.REMOVE) können 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.

Icon

Achtung: Mit jadice web toolkit 5.5.0.0 ist PredefinedAnnotationRenderStrategy.CLIENT der Default. Zum serverseitigen Maskieren sensibler Dokumentinhalte muss dann explizit PredefinedAnnotationRenderStrategy.SERVER_SIDE_MASKING.applyToDocument(Document) gesetzt werden.

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 auslösen: 

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);
}
}
   getPageView().repaint();
   ToolManager tm = leftViewer.getPageView().getToolManager();
ThumbnailTool thumbnailTool = tm.getTool(ThumbnailTool.class);
thumbnailTool.getThumbnailView().repaint();
}
};

(Warnung) Einen kleinen Fallstrick gibt es jedoch dabei: möchte man, dass die DENY.SHOW-Permission beim Ausdrucken des Dokuments Anwendung findet (und somit die versteckten Annotationen auch im Ausdruck versteckt werden), so muss die Information, welche der Annotationen ausgeblendet sind, beim Ausdruck an den Server transportiert werden. 

  • Einfachste Variante wäre das Setzen von annotation.setModified() auf den mit DENY.SHOW belegten Annotationen vor dem Aufruf der ServerOperation. Dies kann nun aber in der Folge zu Problemen beim Speichern von Annotationen per ServerOperation führen. Obwohl die Annotation eigentlich schon gespeichert war und nicht verändert wurde, ist sie nun am Client als "modified" markiert und wird in allen ServerOperations mit diesem Zustand an den Server übertragen.
  • Besser ist es, die versteckten Annoationen beim Ausdrucken über die ServerOperationParameters-Implementierung an den Server zu übermitteln. Wie genau diese Implementierung aussieht (Liste von Annotation-IDs,...), bleibt der konkreten Integration überlassen. Serverseitig muss die kundenseitige Implementierung der Druck-ServerOperation diese Information geeignet auswerten und verarbeiten.

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 Tücken zu beachten. Sogar noch einfacher geht das, wenn man die dokumentweiten Berechtigungen verwendet:

private final AbstractPageViewCommand cmdAllow = new AbstractPageViewCommand() {
@Override
protected void execute() {
    UIDocument<IsWidget> document = getPageView().getDocument();
    clearAnnoChangeANDRemovePermissions(document);
document.getPermissions().getPermissions().add(DocumentAnnotationPermission.ALLOW.REMOVE);
document.getPermissions().getPermissions().add(DocumentAnnotationPermission.ALLOW.CHANGE);
   getPageView().repaint();
ThumbnailTool thumbnailTool = tm.getTool(ThumbnailTool.class);
thumbnailTool.getThumbnailView().repaint();
  }
};