Strategie bei ScriptLibraries

[TMC]

Jeder Programmierer hat ja wiederverwendbare Routinen, und lagert diese wohl in ScriptLibraries aus.

Ich habe mir angewohnt, folgende Basis-ScriptLibs zu haben:

• LibStandard (Sämtliche Backend-Routinen um Arrays zu behandeln, Stringfunctions, DateTime-Functions, ErrorHandling-Routinen, etc.)
• LibStandardUI (sämtliche allgemein verwendbare UI-Routinen)
• LibStandardNotesAPI (Routinen, die die NotesAPI verwenden, z.B. ProgressBar)
• LibStandardWinAPI (Routinen, welche die WinAPI verwenden, z.B. BrowseFolder)
• .. weitere individuelle Libs

Die LibStandard wird in den anderen Libs immer per Use "LibStandard" eingebunden.

Außerdem werden alle oben erwähnten Libs in all meine DB's kopiert.
Die LibStandard brauche ich praktisch überall (Masken, Views, Agents, etc.).

Bei Bedarf kommt dann noch der Rest hinzu. Applikationsspezifische Libs kommen in der Regel in:

• LibApplication
• LibApplicationUI
• LibApplicationNotesAPI
• LibApplicationWinAPI

Wobei auch all diese Libs wieder ein Use "LibStandard" enthalten.

Wenn ich nun in einer Maske z.B. die 'LibApplicationUI' brauche, dann steht in der Maske:
Use "LibStandard" '(weil eh IMMER dabei)
Use "LibApplicationUI"

Aber dadurch werden ja Libs mehrfach geladen (in diesem Beispiel die "LibStandard" doppelt).

Lässt sich das sinnvoll vermeiden, ohne die Übersicht zu verlieren? Gerade die Kombination von Libs kann ja da schnell mal ein mehrfaches Laden von Libs hervorrufen, andererseits soll die "Gliederung" IMHO möglichst durchschaubar und einfach bleiben.

Ich habe auch schon gesehen/gelesen, dass Leute Container-Libs verwenden. Also Libs, die keinen Code enthalten, sondern nur Use statements, um Libs einzubinden. Ich weiß aber auch nicht, ob mich das wirklich weiterbringt.

Wie ist da Eure Strategie? Was würdet Ihr empfehlen?
Meine "LibStandard" enthält aktuell etwa 80 subs/functions + ein paar Klassen. Laded aber sehr schnell.

[Axel]

Ich habe auch schon gesehen/gelesen, dass Leute Container-Libs verwenden. Also Libs, die keinen Code enthalten, sondern nur Use statements, um Libs einzubinden. Ich weiß aber auch nicht, ob mich das wirklich weiterbringt.

Hi Matthias,

ich denke mal, das ist nur Ersparnis bei der Tipparbeit und verhindert den einen oder anderen Fehler. Man bindet eine Lib ein und hat auf einen Schlag alle die man braucht. Ist, denke ich, eine Philosophie-Frage. Was mir bei der Sache nicht ganz klar ist, wenn du so eine Container-Lib hast und du rufst eine Funktion aus einer der eingebundenen Libs auf, ob er dann alle Libs lädt.

Bei einer einzelnen, lädt er ja, soweit ich das mal gelesen habe, alles was in der Lib enthalten ist.

Bei den Klassen hab ich mir angewöhnt, pro Klasse eine Lib zu bauen. Das ist für mich am übersichtlichsten. Bisher bin ich eigentlich ganz gut damit gefahren.

Deine Standard-Lib mit 80 Funktionen und Subs würde ich versuchen aufzuteilen. Vielleicht thematisch, in Stringfunktionen, Datumsfunktionen usw. Bei der Anzahl verlierst du doch sehr leicht den Überblick, oder?

Axel

[TMC]

Deine Standard-Lib mit 80 Funktionen und Subs würde ich versuchen aufzuteilen. Vielleicht thematisch, in Stringfunktionen, Datumsfunktionen usw. Bei der Anzahl verlierst du doch sehr leicht den Überblick, oder?

Das hatte ich früher so. Aber mich hat es genervt wenn ich z.B. einen Agenten schrieb:
Erstmal die LibArray eingebunden. Dann brauchte ich noch Date/Time - Functions. Dann später vielleicht noch was zur String-Bearbeitung.
Daher habe ich das alles revidiert und unterscheide nur noch zwischen Backend und Frontend.

Das ganze ist auch sehr übersichtlich, Beispielauszug wie das aussieht auf der linken Seite der ScriptLibs:

• Array_IsEmpty
• Array_IsMember
• Array_Subset
• DB_GetProfileFieldValue
• Doc_GetAttachmentsSize
• DT_Adjust
• OS_WinTemp

D.h. ich arbeite mit Präfix zur Gliederung.
Der ScriptSorter von der Sandbox sortiert mir die ScriptLibs dann noch bei Bedarf alphabetisch.
Große Klassen kommen bei mir aber auch in separate Libs.

Mit der Container-Lib bin ich mir auch nicht wirklich sicher, ob einen das wirklich weiterbringt.

[koehlerbv]

Grundlegend verwende ich das gleiche Vorgehen wie Du, Matthias. Libs werden freundlicherweise nicht doppelt geladen, trotzdem achte ich peinlich darauf, dass es schon konzeptionell nicht passiert, Libs doppelt zu "usen".

Wie auch Axel halte ich aber Libs mit mehr als 80 Funktionen als Standard-Lib für überdimensioniert - sowas sollte man aufteilen. Vielleicht weniger nach Art der Funktionen, als vielmehr nach erwarteter Wahrscheinlichkeit der Verwendung) okay, hat auch mit der Funktionseingruppierung zu tun).

Auf jeden Fall: Ein hochinteressantes Thema, bei dem wir sicher alle noch was lernen können.

Bernhard

[Axel]

Der ScriptSorter von der Sandbox sortiert mir die ScriptLibs dann noch bei Bedarf alphabetisch.

Hab' garnicht gewusst, dass es so ein Teil gibt. So was habe ich schon lange gesucht. Vielen Dank für den Tipp.

Ich habe mir das Teil mal runtergeladen und werde es mir mal anschauen.   

Auf jeden Fall: Ein hochinteressantes Thema, bei dem wir sicher alle noch was lernen können.

Sehe ich auch so. Wäre doch auch was für die Best Practices, oder?

Axel

[TMC]

@Bernhard: Jo, das Thema finde ich auch sehr interessant.

Libs werden freundlicherweise nicht doppelt geladen, trotzdem achte ich peinlich darauf, dass es schon konzeptionell nicht passiert, Libs doppelt zu "usen".

Wie setzt Du das um, damit Libs nicht doppelt geladen werden und das ganze Konstrukt noch übersichtlich bleibt?

@Axel:
Ja, der ScriptSorter ist echt praktisch. Und erstellt auch Backups der ScriptLibs. Hatte aber noch nie den Fall, dass der mir eine ScriptLib zerstört hat, aber man weiß ja nie, NSF-Backup vorher schadet sicherlich nicht.


Etwas am Rande des Themas:
Ich habe mir auch angewohnt, in den Routinen immer zu erwähnen, welche anderen Routinen dort verwendet werden. D.h. wenn ich in einer Routine die Function Array_Sort verwende, dann gibts in der Routine eine Section "Used procedures: - ArraySort". Umgekehrt möchte ich das für meine Standardlibs auch noch machen, also eine Section "Called by:".

[koehlerbv]

Wie setzt Du das um, damit Libs nicht doppelt geladen werden und das ganze Konstrukt noch übersichtlich bleibt?

Durch Disziplin  Das "doppelt laden" vermeidet allerdings Notes selber (so war der Ausspruch gemeint).

Etwas am Rande des Themas:
Ich habe mir auch angewohnt, in den Routinen immer zu erwähnen, welche anderen Routinen dort verwendet werden. D.h. wenn ich in einer Routine die Function Array_Sort verwende, dann gibts in der Routine eine Section "Used procedures: - ArraySort". Umgekehrt möchte ich das für meine Standardlibs auch noch machen, also eine Section "Called by:".

Letzteres solltest Du meines Erachtens wieder vergessen: Das ist praktisch unpflegbar (Du arbeitest ja mit den Libs nicht nur in einer, sondern in zig Apps). Für sowas verwende ich den Teamstudio Analyzer: Wenn nach ausgiebigen Tests und langer praktischer Verwendung doch herausstellt, dass eine allgemeine Routine geändert werden muss (hinsichtlich Parametern), dann scanne ich das Vorkommen und bessere (zähneknirschend und mich permanent geisselnd) die Calls aus.

Wegen xxxLib und xxxUILib: Ich packe in die UILibs das Zeugs, was ausschliesslich aus dem Frontend aufgerufen werden darf. Da es aber auch Routinen gibt, die so oder so verwendet werden, verwende ich folgende Strategien:

1. Wo machbar und nötig, haben die Routinen zwei standardisierte Parameter:
- Aufruf aus Front- oder Backend ?
- Returnstring by reference, der Meldungen an die aufrufende Routine zurückgibt. Frontend-Meldungen (insbesondere Messageboxes) erfolgen nur, wenn der Aufruf aus dem Frontend geschieht.

2. Wenn diese Unterscheidung partout nicht möglich ist oder absolute UI-NoNos verwendet werden müssen (wenn es denn im UI läuft), binde ich den UI-Code via Execute ein. Hilfreich besonders bei umfangreichen Routinen, die man nicht separat für Front- und Backend schreiben sollte (um die Pflege und damit die Code-Sicherheit zu erleichtern).

Bernhard

[TMC]

Zum Thema "Called by":
Da hast Du natürlich Recht. Ich meinte das auch nur für meine Standard-Routinen. Wenn man in einer App-Lib eine Standard-Routine verwendet macht es IMHO natürlich auch keinen Sinn, in der Standard-Routine was in "Called by" einzutragen.

Zu "doppelt laden":

Ich habe ja oben geschrieben:

Wenn ich nun in einer Maske z.B. die 'LibApplicationUI' brauche, dann steht in der Maske:
Use "LibStandard" '(weil eh IMMER dabei)
Use "LibApplicationUI"

Soweit ich das verstehe, könnte man da "LibStandard" streichen, weil diese ja bei mir mit in der "LibApplicationUI" geladen wird.
Enthält diese use-Statement - Liste nun aber z.B. 8 Statements, so kann das übersichtlich werden, weil man ja dann z.B. 3 wieder streichen kann. Sobald man eine Lib hinzufügt, muss man erstmal überall nachsehen, ob diese denn nicht schon geladen wird.
Außerdem sieht man dann nicht auf 1 Blick in einem Designelement, was denn nun tatsächlich alles geladen wird.

Aber das lässt sich wohl auch nicht vermeiden, oder?

[Glombi]

Noch etwas zum Thema:
Ich tendiere dazu, das Option Public auszukommentieren bzw. explizit für alles erstmal ein Private zu schreiben.

Es ist grauenvoll, wenn man andere Libraries verwenden will und dann ständig die Meldung bekommt "das ist hier schon definiert und das da...".
Also nur die aufrufenden Subs / Functions / Classes als Public. Ausserdem sollten diese Public Dinge dann sprechenden individuelle Namen haben, will heissen
public LAUI_ws as NotesUIWorkspace
wenn das Ding in der SL LibApplicationUI ist
und nicht ws.

Andreas

 

[TMC]

Danke auch für Deine Erfahrung, Andreas.

Ich glaube Thomas Völk hatte mich damals beim Thread "Wie kann ich eine Klasse sinnvoll aufbauen" darauf gebracht, und seitdem mache ich das auch so:
"Option Public" raus. Und jede Routine bekommt ein Private oder Public vorangestellt.
Da weiß man was man hat 

Matthias

P.S. ich ändere mal oben den Betreff von "Strategie beim Laden von ScriptLibraries" in "Strategie bei ScriptLibraries".  Alles sehr interessant.

[koehlerbv]

Private & Public sind auch wichtige Hinweise. Allerdings sollte man sich schon Gedanken machen, wenn man beim Einbinden darauf hingewiesen wird, dass das schon deklariert wurde. Da sollte man im Vorfeld schon mehr Sorgfalt walten lassen.

Jedenfalls: Was Private & Public angeht, werde ich auch mal an das Überarbeiten gehen. Da muss ich nämlich auch mal wieder aufräumen ...

Bernhard

[theBastian]

Guten Morgen,

oute mich mal als Newbie in Sachen Programmierung, finde aber Eure Ausführungen sehr interessant, da es m.E. keine "offizielle" Regelung gibt, wie man bei Script und Co. verfahren sollte.

Mir und sicher vielen anderen würde aber neben den Ausführungen sicher eine Demo-DB helfen, die aufzeigt, wo was eingetragen oder definiert werden sollte.

Diese DB muss nicht Codes oder so enthalten, sondern eher sowas wie z.Bsp:

ScriptLibraries: "hier sollten globale variablen mit PUBLIC deklariert werden"

Quasi ein Beispiel, wie man eine DB aufbauen sollte, damit auch später mal andere was mit anfangen können.

cu
Sebastian