Deklarationen: wie macht man's richtig richtig?

[cpo]

Hallöchen,
ich oute mich jetzt und hier mal als Nicht-IT-Studierte, die mit Notes 3 groß geworden ist und dann irgendwann mal Script gelernt hat.
Soll heißen, dass ich z.b. das Dim session as New NotesSession einfach mal immer getippt habe, ohne genau zu raffen, warum, weshalb und wieso  

Mittlerweile scripte ich zwar fast nur noch, mir fehlt aber immer noch der ultimative Durchblick bei den Deklarationen.

Wie macht ihr das? Dimt ihr die session in jeder library neu? Nutzt ihr Private? Wohin mit Objekten, die man ständig und überall braucht? (z.B. die aktuelle datenbank oder irgendeine referenzierte)

CPO

[Glombi]

Hi, ich fang mal an...
Generell:
Ich habe für mich entschieden, Dim und Set immer zu trennen.
Das Dim kommt immer in Declarations und Set dann wo man/frau es braucht.

Was oft Sinn macht (muss halt von DB zu DB geprüft werden):
Häufig verwendete Objekte wie NotesSession und NotesDatabase können in einer Script Library dimensioniert und dort im Initialize gesetzt werden.
Als Name nehme ich dann sowas wie
dim GLOBALS_session as NotesSession
dim GLOBALS_db as NotesDatabase

wobei "GLOBALS" den Name (zumindest eindeutiges Präfix) der Library ist. Dann weiss man später im Script immer, wo die Dinger herkommen.

In Masken macht es Sinn, unter (Globals) folgendes zu deklarieren:
dim uidoc as NotesUIDocument
dim doc as NotesDocument

und das dann im Postopen/Queryopen zu setzen.

Tip:
Alle Objekte, die in Script Libraries unter (Declarations) deklariert werden und die NUR INNERHALB der Library verwendet werden, als Private deklarieren. Sonst kann es Stress geben, wenn man nachträglich eine Library bspw. in eine Maske einbindet und gleiche Namen verwendet.

Bei der Verwendung von UI-Klassen ist bzgl. Script Libraries folgendes anzumerken:
Alle Objekte, Functions etc. die UI-Objekte verwenden, behandle ich in einer eigenen Script Library. Es gibt nämlich die Einschränkung, dass diese Libaries nicht in servergestützten Agenten verwendet werden können (sonst kommt Error Use lsx oder sowas).

to be continued...

Andreas

[cpo]

hmpf
dann mache ich irgendwas noch falsch...

Ich hatte mir das nämlich auch genau so überlegt: eine lib in der z.B. eine Datenbank auf die ich immer mal wieder referenziere gedimt und gesetzt wird. Dim in den Declarations, set im initialize.

Der Plan war dann, EINMAL initialisieren zu lassen und danach meine MAIN_dbAddress IMMER Verfügung zu haben.
Das klappt aber leider so nicht... Ich spare mir zwar Tipparbeit, die Globals beiben aber nicht Global...
Das wiederum bedeutet, dass ich ständig die Datenbank neu setzte und das bedeutet, dass es grottig langsam wird...
Mache ich da noch einen Denkfehler?

Bei den UIObjekten habe ich übrigens festgestellt, dass man das ein bisschen austricksen kann, indem man sie als Variant dimt und den set bei bedarf macht. Machte aber nur in dem Fll Sinn, weil in einer lib mit 1000 Funktionen nur eine war, die UI brauchte.

[Glombi]

Hi,
Du machst aber überall ein
Use "Name der Script Library"
wenn Du "MAIN_dbAddress" brauchst, oder?

Wegen der UI-Objekte: Ja, das mit Variant geht (macht Lotus auch im Mail). Finde ich persönlich aber nicht so schön.

Andreas

[ata]

... Variant verwende ich, wenn ich rekompilieren muß...

ata

[Glombi]

... Variant verwende ich, wenn ich rekompilieren muß...

... und warum?

Ist vielleicht schon zu spät und eknori hat mich aus der Fassung gebracht, aber ich komm nicht drauf. Brauche vielleicht auch Urlaub

Andreas

[ata]

... sorry für die späte Antwort...

wenn ich mit Klassen arbeite, und in einer Klasse eine neu Instanz aufnehme oder ändere, dann muß ich überall dort, wo die Lib verwendet wird neu kompilieren - dann deklariere ich kurz mit "... as Variant" - speichere - deklariere wieder richtig - speichere und alles ist wieder in bester Ordnung...

ata

[cpo]

ebenfalls sorry - das Wetter war zu gut  

ata: Ja, ich habe überall den use "blablabla" drin. In den Globals ist dann auch die variable - nur isse leider wieder nicht gesetzt.
das bedeutet, dass ich sie jedesmal neu "initialisieren" muss - und das wollte ich grad vermeiden  

Aber weiter oben (hm, nach dem Posting dann wohl weiter unten) war auch die Antwort auf die Frage: Es gibt einfach keine datenbankglobalen Variablen! Sehr, sehr schade..

CPO

[ata]

... global in der Datenbank mit Variablen arbeiten geht nur über den Umweg von Profildokumenten - oder bei geringen Anforderungen die Notes.ini...

... Objektvariablen sind nicht möglich...

ata

[Axel_Janssen]

Profildokumente finde ich auch nicht so toll (obwohl sie Performance-mässig sicher sehr gut sind). Unter 4 hatte ich mal gewaltige Probleme im Kontext von Replikation und danach waren die Dinger für mich gestorben. Weiß nicht ob das Problem noch fortbesteht.

Ich arbeite für globale Daten immer mit einem einfachen Dokument mit einer Maske config und einer view config. In dieser view ist immer genau ein Dokument (es ist somit quasi wie ein Singleton-Objekt in OO mit state aber ohne behaviour).
Man hat dann direkt auch eine einfache/übersichtliche Möglichkeit zur Parametrisierung von Anwendungs-globalen properties für Kunden/Endanwender.  

Bei ini-Variablen sollte man sich genau Gedanken machen, wann diese eventuell gelöscht werden. Viele Leute vergessen das. Ansonsten ist dies zwar völlig old-school und error-prone, aber manchmal eben auch ganz nützlich.

[Glombi]

Für INI-Variablen sprechen: Verwendbarkeit auch über mehrere Datenbanken hinaus, z. B. Telefonnummer, Personalnummer, Abteilung....
Dagegen spricht: Nicht web-fähig, bei Neuinstallation oder Rechnerwechsel keine Daten oder die vom Kollegen.

Bei den Konfig-Dokumenten muss auch die ACL beachtet werden: Die User müssen das Recht haben, Dokumente zu erstellen, d.h. für Leser geht das nicht. Das könnte man aber umegehen, wenn man eine extra Konfig.-Datenbank mitführt.

Andreas

[cpo]

Yep, alles richtig, aber entscheidend ist die Aussage von ata: Keine DB-globalen Objekt-Variablen (Danke, ata)
Das Problem ist doch einfach die Performance: Wenn ich eine verlinkte DB immer wieder btrauche, muss ich sie immer wieder setzten und LS braucht immer wieder tierisch lange...
OK - hab' ich aber jetzt begriffen: geht nich  

Profildokumente nutze ich eigentlich ständig. Seitdem wir sie nicht mehr für Sachen nutzen, die sich ständig ändern (Zähler...) gibt's auch keine Probleme mehr in Clustern...

Ini-Einträge haben seit den Profiles bei mir deutlich abgenommen. Nehme ich eigentlich nur noch, wenn ich wirklich DB-übergreifend und userspezifisch irgendwas speichern will. Oder wenn halt mal ganz schnell ein Text von Script an @@ übergeben werden muss  

CPO