Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.



Steuerung des Verhaltens, ob Annotationen server- oder clientseitig gerendert werden, Die Anleitung wurde für jadice web toolkit Version 5.4.11.0 erstellt.

steuern kann, ob Annotationen server- oder clientseitig gerendert werden,

Seiteneigenschaften
Zusammenfassung
Panel
borderColor#ff8c1a
titleColor#ffffff
borderWidth2
titleBGColor#ff8c1a
borderStylesolid
titleGültig ab JWT Version 5.4.11.0

Diese Anleitung beschreibt, wie man mittels PredefinedAnnotationRenderStrategy.CLIENT und PredefinedAnnotationRenderStrategy.SERVER_SIDE_MASKING

.
JWT Version


Status Quo

Annotationen werden im JWT 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.

...

  • 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.

...

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 kann pro Dokument gesetzt werden - damit ist der Integrator flexibler.

Info

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

...

  • 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:

...

Hier gibt es keine weiteren Tücken zu beachtetn.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();
  }
};