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 : 

...

• Einfachste Variante wäre das Setzen von annotation.setModified() auf den mit DENY.SHOW belegten Annotationen vor dem Aufruf der ServerOperation. Dies kann nun umgekehrt aber in der Folge zu Problemen beim Speichern der 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 folgenden 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 entsprechend 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 Fallstricke, die einem das Leben schwer machenTücken zu beachtetn.