eingebettete Ansichten zur Laufzeit füllen

[Alexander 28]

Hallo liebe Entwicklerkollegen!

Ich habe eine Schüssel-Datenbank, in der ich vor folgendem Problem stehe.

Es gibt eine Ansicht mit Dokumenten in denen Räume gespeichert werden. In einer anderen Ansicht gibt es Dokumente in denen Schlüssel gespeichert werden. Nun möchte ich im Schlüsseldokument Räume zuordnen, die dieser Schlüssel schließt. Ich möchte also in den Schlüsseldatensatz eine Ansicht einbetten und über eine PickList die betreffenden Räume auswählen, die dieser Schlüssel schließt. Diese sollen dann in der eingebetteten Ansicht im Schlüsseldokument angezeigt werden.

Bisher habe ich solche Anforderungen immer so gelöst, dass ich die UniID des Schlüsseldokumentes in das jeweilige Raum-Dokument eingetragen habe und auf Basis dieser UniID über SingleKategorie nur die Dokumente angezeigt werden, in denen die Uni ID des UIDocs stehen. Das funktioniert soweit ja eigentlich auch einwandfrei. Das Problem in diesem konkreten Fall besteht darin, dass derjenige, der den Schlüssel bearbeitet und die Räume zuordnen will unter Umständen kein Bearbeitungsrechte für die Raumdokumente hat. Somit kann er die UniID des Schlüssels dort nicht speichern.

Unter Umständen wäre es jetzt sicherlich möglich, das ganze über einen Agenten per RunOnServer zu lösen, allerdings halte ich das ebenfalls nicht für die glücklichste Lösung.

Ich habe nun schon viel und her hin und her überlegt ob man das gegebenenfalls auch irgendwie über Ordner oder sonst irgendwie anders lösen könnte!?!?!
Vielleicht verfolge ich auch einen völlig falschen Gedankenansatz. Hat der ein oder andere von euch eine Idee, wie man so etwas cleverer lösen könnte. Ist ja eigentlich eine Standardanforderung, die man immer mal wieder benötigt.

Herzlichen Dank im Voraus an alle Tippgeber ….

[Peter Klett]

AgentRunOnServer finde ich nicht das schlechteste. Alternativ könntest Du die Raumdokumente technisch bearbeitbar lassen (z.B. Autorenfeld mit "*", aber den Inhalt des Dokumentes mit einem zugriffsgesteuerten Abschnitt schützen). Im Frontend ist das Raumdokument dann nicht bearbeitbar, aber natürlich von jedem (oder jedem Schlüsselbearbeiter) änderbar.

Noch ein Lösungsansatz wäre, separate Dokumente für den Raumzugriff zu halten, diese Dokumente enthalten nur die Information über den Raum und den Schlüssel. Für jeden Zugriff wird ein Dokument erstellt. Diese Dokumente werden in der eingebetteten Ansicht angezeigt (geht sowohl in den Räumen als zugeordnete Schlüssel, als auch umgekehrt in den Schlüsseln als zugeordnete Räume). Im QueryOpenDocument der jeweiligen Ansicht biegst Du das Öffnen um auf das jeweils gemeinte Dokument (also Raum oder Schlüssel).

Nachteile: Unter Umständen hast Du sehr viele dieser Zugriffsdokumente (1000 Räume mit 500 Schlüsseln kann sich ganz schön summieren), außerdem musst Du diese Dokumente konsistent zu den "Hauptdokumenten" halten, also Umbenennung von Raum und Schlüssel muss mitgezogen werden.

Strukturell erscheint es mir trotzdem das sauberste zu sein. Die Zugriffsdokumente werden (außer in den eingebetteten Ansichten) generell nicht angezeigt, können von jedem bearbeitet werden (Autor = "*") und werden bei Nichtgebrauch zur Wiederverwendung recycelt (also nicht löschen, da fehlt sowieso das Recht zu, sondern Information über Raum und / oder Schlüssel entfernen, bei Neuerstellung nach solchen nichtbenutzten Dokumenten suchen und neu füllen)

[Alexander 28]

Hi Peter, vielen Dank für die ausführliche Antwort.

Ja, der Gedankenansatz ist nicht schlecht, werde ich mal drüber nachdenken. Du hast aber natürlich vollkommen recht, die Anzahl der Dokumente bei mehreren 100 Räumen kann sich sehr schnell summieren. Hier sehe ich Moment das größte Problem, da die Anwendung an sich ohnehin schon nicht sehr performant ist.

[thkn777]

Zur Lösung mit den "Link" Dokumenten noch ein paar Anmerkungen:
- eindeutige, nicht wiederverwendete Schlüssel für Räume und Schlüssel können helfen, das Update-Problem der Link-Dokumente zu minimieren
- eine Performance-Verschlechterung muß gar nicht mal auftreten. Im Moment muß Notes in den eingebetteten Ansichten ggf. die Leser/Autorenfelder der Räume prüfen. Wenn Link-Dokumente auf Leser/Autorenfelder verzichten, kann das durchaus einen Performance-Schub geben. Nachteil: es wird dem Nutzer zu einem Schlüssel ggf. ein Raum angezeigt, auf den er keine Leserechte hat. Erst beim Versuch, das Raumdokument zu öffnen, käme dann ein Fehler. Ich glaube zwar nicht, daß dieser Fall bei Dir auftritt, er ist aber denkbar.

Viel Erfolg bei der Umsetzung,
Th.

[Alexander 28]

hi thkn777, ja - auch das werde ich berücksichtigen. ich bin gerade dabei die Routine zum Erzeugen der temporären Verknüpfungsdokumente zu schreiben und werde einmal beide Konstellationen durchprobieren, einmal mit der Übernahme der Berechtigungsfelder aus dem Raum-Dokument und einmal ohne. Ich kann mir aber eigentlich nicht vorstellen, dass dies im Bezug auf die Performance in der eingebetteten Ansicht einen wesentlichen Unterschied macht.

Ich werde auf jeden Fall hier meine Ergebnisse posten!