Übergreifende Variablen

[DaHias]

Moin Moin,

Ich stehe momentan vor folgender Herausforderung gegenüber:

Ich habe eine Rahmengruppe mit einer Maske oben (fest als Navigation) und ebenfalls einer Maske unten (die variabel ist). Nun will ich beim Laden der Datenbank Variablen laden, auf die ich dann beim Benutzen der Datenbank an jeder Stelle zugreifen kann.

Das heißt also im Grunde, dass ich globale Variablen will (die der Benutzer später auch spezifisch anpassen darf) die beim Start geladen werden und egal welchen Punkt ich in der Navigation auswähle ich immer auf diese Variablen zugreifen kann.

Habt ihr vielleicht ein paar Tipps für mich? (außer ich soll das lassen, weil ich will das schon versuchen :p)

Grüße,
Mathias

[Axel]

Entweder du arbeitest mit einem Profildokument und bietest dem User über eine Maske die Felder zum Verändern an, oder du legst ein Konfigurationsdokument an und greifst dann z.B. mit @Dblookups auf die Feldinhalte zu.


Axel

[DaHias]

Aber wie krieg ich dann die Werte so, dass ich wirklich immer drauf Zugriff hab?

Klar wenn ichs inner Navigation oben einmal abfrage hab ichs da drin, aber ich kann mir die dann nich unten anzeigen lassen.

[Axel]

Aber wie krieg ich dann die Werte so, dass ich wirklich immer drauf Zugriff hab?

Überall wo du sie brauchst greifst du mit @Dblookup oder ähnliche Methode darauf zu.

Klar wenn ichs inner Navigation oben einmal abfrage hab ichs da drin, aber ich kann mir die dann nich unten anzeigen lassen.

Das verstehe ich jetzt nicht so ganz.

Was soll denn das überhaupt werden. Gibt mal ein paar mehr Infos.

Axel

[DaHias]

Also im Grunde will ich die nicht immer da abfragen müssen, wo ich die Variablen brauche. Z.B. will ich die auch in Hide/Whens einsetzen und da jedes mal einen Lookup zu fahren finde ich nicht sehr elegant.

Das ganze soll eine Art "Zusammenstellung" aus verschiedenen Workflows sein. Der Anwender bestimmt, welche Workflows ihn interessieren und diese kann er sich dann einblenden bzw. wenn kein Interesse besteht ausblenden lassen. Soll eben so alles sehr flexibel gehalten werden.

Und dem Benutzer soll die Möglichkeit gewährt werden über eine Konfiguration per Kontrollkästchen zu bestimmen, was er sehen will. Und genau diese Konfiguration will ich nun beim Start der Datenbank benutzerabhängig laden.

[Axel]

Also im Grunde will ich die nicht immer da abfragen müssen, wo ich die Variablen brauche. Z.B. will ich die auch in Hide/Whens einsetzen und da jedes mal einen Lookup zu fahren finde ich nicht sehr elegant.

Um die Abfragen wirst du aber nicht drumrum kommen. Für die Hide-Whens kannst du ja ein verstecktes berechnetes Feld in die Maske einfügen. Dort machst du den Lookup und beziehst dann in den Hide-When - Formeln darauf.

Flexibilität eine Anwendung ist nun mal etwas aufwändiger. 

Axel

[DaHias]

Wie würde es denn mit Profil-Dokumenten aussehen? Hast du damit Erfahrung?

[Gandhi]

Was ist denn mit der guten alten Notes.ini - nur mal so als Alternative.
Wenn die Variable nicht gespeichert werden muss halte ich das für angenehmer.
Ansonsten kannst Du Dir eine Variable über ein gemeinsames Feld mit geringem Aufwand an den meisten Stellen vorhalten - das spart dann ein paar Zugriffe.

[koehlerbv]

Das mit der NOTES.INI findet aber nicht jeder Admin soo toll - die ist ganz schnell unübersichtlich zugemüllt.
Gemeinsame Felder sind kein Ersatz für "globale Variablen". Sind es berechnete Felder, dann spart man sich Arbeit.

Profildokumente haben den grossen Vorteil, dass sie im Cache gehalten werden, also bestmögliche Performance besitzen.

Bernhard

[DaHias]

Leider bin ich auch einer von denen, der nicht so begeistert von der Methode mit der Notes.ini ist.

Ja gut mit berechneten Feldern spar ich mri die Arbeit jedes mal wieder son einen Lookup zu machen, aber auch damit brauch ich die ja in jeder Maske und das will ich eben genau nicht.

Das mit den Profildokumenten klingt eigentlich sehr vielversprechend, vor allem kann ich es damit gut benutzerspezifisch gestalten. Und dass die im Cache gehalten werden, wie es Bernhard schreibt, hab ich gelesen und finde ich auch top da ich doch einige Male darauf zugreifen werde.

Ich werde es jetzt also erstmal mit den Profildokumenten versuchen.

Vielen Dank für alle Tipps!

Mathias

[Axel]

Das mit den Profildokumenten klingt eigentlich sehr vielversprechend, vor allem kann ich es damit gut benutzerspezifisch gestalten. Und dass die im Cache gehalten werden, wie es Bernhard schreibt, hab ich gelesen und finde ich auch top da ich doch einige Male darauf zugreifen werde.

Aber Achtung! Einen Fallstrick hat das Ganze. Werden Werte in Feldern des Profildokumentes geändert, werden sie erst nach einem Neustart der Datenbank gültig.

Axel

[koehlerbv]

Die ursprüngliche Fragestellung deutet darauf hin, dass es sich um benutzerabhängige Variable handelt, ergo sind persönliche Profildokumente zu verwenden. Damit entfällt der Fallstrick, Axel.

Bernhard

[LN4ever]

Lieber Mathias,

überleg dir gut, wie du mit Benutzern umgehst, die nur lesenden Zugriff auf deine DB haben. Die können evtl. kein Profildokument anlegen.

@Axel:
Ein bereits angelegtes Profildokument kann jeder (auch ein lesender Benutzer) verwenden und die Werte für seine Session auch überschreiben. Während der Session stehen ihm seine Werte (gecached) an jeder Stelle zur Verfügung. Man kann so etwas bei der Übertragung von Suchstrings oder Spracheinstellungen, die der Benutzer einmalig am Anfang der Sitzung vornimmt, gut einsetzen. Da turnen Hundert Benutzer auf einem einzigen von einem Editor angelegten zentralen Profildokument herum - und jeder hat nur seine eigenen Werte zur Verfügung.

Gruß

Norbert

[DaHias]

@Norbert: Autorenrechte sollten aber ausreichen oder? So war es zumindest angedacht.

Also was ich bis jetzt gesehen habe, klappt das mit den Profildokumenten ganz gut und ich krieg damit auch genau das hin, was ich wollte.

[LN4ever]

Lieber Mathias,

natürlich reichen Autorenrechte aus. Ich setze normalerweise noch ein Feld $PublicAccess BERECHNET BEIM ANLEGEN mit dem Wert "1" ein, damit der Zugriff nicht abgeschottet wird (in einem solchen Dokument stehen ja keine Geheimnisse drin).

Bei Profildokumenten ist eine wichtige Grenze zu beachten: In einer Datenbank darf die Summe aller Profildokumente ca. 6000 nicht übersteigen. Das erscheint auf ANhieb eine große Zahl, aber wenn du bedenkst, daß es eine ganze Reihe von halböffentlichen Code-Schnippseln gibt, die Userprofildokumente benutzen,  kann sich die Zahl schnell erhöhen. Und es ist die Vorabwarnung: für große Datenbanken mit sehr vielen Benutzern kannst du das gleich wieder knicken.

Dann mußt du den Weg gehen, den ich oben angedeutet habe: Jeder Benutzer hat ein "normales" Definitionsdokument, dessen Inhalte zu Beginn der Sitzung in das eine öffentliche Profil-Dokument kopiert werden (das der User niemals speichert). Damit stehen dir die Caching-Geschwindigkeitsvorteile zur Verfügung, die Profildokumente bieten und du bist in der Zahl der Benutzer nicht eingeschränkt.

Gruß

Norbert

[Axel]

@Axel:
Ein bereits angelegtes Profildokument kann jeder (auch ein lesender Benutzer) verwenden und die Werte für seine Session auch überschreiben. Während der Session stehen ihm seine Werte (gecached) an jeder Stelle zur Verfügung. Man kann so etwas bei der Übertragung von Suchstrings oder Spracheinstellungen, die der Benutzer einmalig am Anfang der Sitzung vornimmt, gut einsetzen. Da turnen Hundert Benutzer auf einem einzigen von einem Editor angelegten zentralen Profildokument herum - und jeder hat nur seine eigenen Werte zur Verfügung.

@Norbert

Mir ist die Funktionsweise (und auch die Fallen) von Profildokumenten durchaus bekannt. Ich habe mich in der Vergangenheit eingehend mit dieser Problematik befasst.

Axel