Domino 9 und frühere Versionen > ND7: Entwicklung

DokumentObjekt als Funktionsrückgabewert?!

<< < (3/4) > >>

TRO:

--- Zitat von: MadMetzger am 18.09.09 - 13:07:45 ---Hm... Was ist, wenn du das Dokument danach noch mal neu über die vorher beschaffte UNID erzeugst?

--- Ende Zitat ---

Mit der NoteID (statt der UNID) wäre das noch performanter, da die NoteID quasi die "natürliche" Ordnung der Notes-Dokumente in einer DaBa darstellt. Da muss dann bei GetDocumentBy(UN)ID nicht der Weg über die interne Tabelle UNID --> NoteID gegangen werden.

Thomas

koehlerbv:
Samuel, das geht ganz einfach auch ohne Verrenkungen und zig Objekten, die auch "aussen" vorhanden sein müssen.

Ein Beispiel:

--- Code: ---Set docTRConfigSetup = GetSetupDocumentFromOtherDB (True, dbTRConfig, "ConfigDBReplicaID", "Global Setup", "TRConfig", szErrorMessage)
--- Ende Code ---

docTRConfigSetup sei als Objekt vorgesehen für das Setup-Dokument der "fremden" Datenbank "TRConfig".

Die Parameter der Routine GetSetupDocumentFromOtherDB sind bis auf einen - siehe unten - der internen Verwaltung geschuldet:

--- Code: --- ' Purpose: Retrieves a named Setup document from another database
'------------------------------------------------------------------------------------------------------------------------------------------------------------
' Arguments:
' bIsInteractive - True if called from the frontend, False otherwise
' dbOther - NotesDatabase object to be returned by reference because the Setup document is a "child" of dbOther
' szItemReplicaID - The item name in the own Setup document which contains the ReplicaID of the other database
' szSetupName - The type name of the Setup document to retrieve in the other database
' szDBTitle - The title of the other database (for possible frontend error messages)
' szErrorMessage - Used to return possible error messages by reference

--- Ende Code ---

"Kriegsentscheidend" ist also nur das Objekt "dbOther", welches vorgesehen ist für den "Vater" des Kindes "Setup-Dokument in dbOther" (wie Markus schon schrieb: Objektorientiert denken!)

Was dbOther übergeben wird, ist wurscht - Hauptsache, es ist wirklich ein NotesDatabase object.

Vor dem Aufruf der Function steht daher:
Dim dbIrgendeinName As New NotesDatabase ("", "").

Das "New Database" könnte aber auch innerhalb der Function gesetzt werden.

Ich hoffe, ich habe damit das Verfahren zum Umgang mit Vererbung und deren Übertragung halbwegs verständlich herüberbringen können.

Bernhard

MadMetzger:
Hm... Bernhard... Ich habe gerade ein Deja-vu... Irgendwie hatten wir genau bei dem Thema die Diskussion, dass es sich bei diesen Beziehungen nicht um Vererbung handelt... In der OO würde man diese Beziehung eher Assoziation nennen. In diesen speziellen Fall könnte man sogar von Aggregation sprechen, da mit Verlust des verweisenden Objektes das abhängige Objekt mit verloren geht.

Zumindest bin ich zu Noteszeiten auch das eine oder andere Mal drauf reingefallen, dass solche Objekte "verschwinden", wenn das verweisende Objekt aus dem Fokus ist.

Um das vielleicht noch etwas aufzuhellen: Vererbung ist eine Beziehung, die man nutzt, wenn man zwei Typen gemeinsames Verhalten (Methoden) und gemeinsame Struktur (Attribute) haben. Genau das liegt hier aber nicht vor, denn ein Dokument und eine View haben eigentlich keine Gemeinsamkeiten (aus OO-Sicht).

TRO:
und hier

http://www.bobzblog.com/tuxedoguy.nsf/dx/geek-o-terica-3-taking-out-the-garbage-lotusscript

beschreibt Bob Balaban (der Chef-Entwickler der LS-Engine) die Hintergründe für diese "verschwindenden" Objekte.


Thomas

koehlerbv:
Jo, diese Begriffe sind natürlich korrekter: Eine "Assoziation" fällt beim Verlassen des encapsulated modules der "garbage collection" zum Opfer.

Hauptsache, man kennt diese Zusammenhänge und sorgt dafür, dass die Müllabfuhr nicht das "falsche" abräumt: NotesDatabase ist in diesem Fall für das "Überleben" des NotesDocuments essentiell. Und es für auch nur einmal im Speicher vorgehalten dank der Reference.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete