Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Seiteneigenschaften
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.

...

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 : 

...

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

...