Domino 9 und frühere Versionen > ND6: Entwicklung

Strategie bei ScriptLibraries

<< < (2/3) > >>

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


--- Zitat von: koehlerbv am 04.03.05 - 20:10:47 ---Libs werden freundlicherweise nicht doppelt geladen, trotzdem achte ich peinlich darauf, dass es schon konzeptionell nicht passiert, Libs doppelt zu "usen".
--- Ende Zitat ---

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:

--- Zitat von: TMC am 04.03.05 - 20:35:58 ---Wie setzt Du das um, damit Libs nicht doppelt geladen werden und das ganze Konstrukt noch übersichtlich bleibt?

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


--- Zitat von: TMC am 04.03.05 - 20:35:58 ---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:".

--- Ende Zitat ---

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:

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

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  :D

Matthias

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete