Ich bin bezügl. Klassen ein Anfänger, da ich noch nie wirklich größere Klassen erstellt habe.

Wie baut Ihr sinnvoll Klassen auf?

Ich nehme als Beispiel eine History-Scriptlibrary, bisher hab ich alles als Subs & Functions in der Lib.

Was passiert:
A) User öffnet ein Dokument
+ Im Postopen werden zu überwachende Feldnamen und Feldinhalte jew. ein eine globale Variable (Array) gesetzt
B) User speichert ein Dokument
+ Im PostSave (nicht Querysave da RTF-Überwachung inclusive):
     - Array-Vergleich vorher / nachher, wenn keine Änderung: mache nix
     - setze History-Log zusammen, dabei Unterschied ob RTF oder nicht
     - Definiere 1. und 2. "Spalte" (durch Tab getrennt), hier Datum und Username
     - Setze String für Textfeld zusammen
     - Hänge Änderungen ans Textfeld an
     - Save

Ziel ist für mich, die Klasse prinzipiell für viele DB's verwenden zu können. Dinge wir den Namen des History-Feldes, die Anzahl der Historien-Einträge, etc. will ich der Klasse übergeben.
Bisher setze ich hier in der ScriptLib auch Standard-Functions wie Explode, Implode, CompareArray etc. ein.

Ich bin für jeden Ansatz dankbar, wie ich das in eine Klasse übernehmen könnte.

ich kenne leider kein Tool, das objektorientierte Programmierung mit Notes irgendwie erleichtert. Hier im Forum wurde mal ein Projekt geboren (lssEclipse), ich glaube aber, dass es nicht mehr sehr lebendig ist.

zum Ansatz, den du wünschst:

schreib doch mal kurz auf, was diese Klasse können soll und, ggf., mit welchen anderen Klassen sie kooperieren soll.

und noch eine Frage hinterher:
warum möchtest du eine Klasse haben? Du hast ja scheinbar schon etwas funktionierendes in deiner History-Scriptlibrary...

Es gibt da so einen Kompromiss, der manchmal ganz nützlich ist: man defniert eine Klasse, die einzelnen Member-Routinen machen aber nichts anderes, als eine normale Sub oder Function aus der gleichen ScriptLib auf. Man achtet dann natürlich darauf, dass beim Verwenden der Klasse nie die Klasse selbst dadurch umgangen wird, dass man die Subs und Functions direkt aufruft. Damit hat man dann aber die gewünschte gewohnte Designer-Darstellung für seine "Methoden".

Class Beispiel
  daten as Datentyp

sub MemberMachIrgendwas (Param As String)
   Call ExtMachIrgendwas (Param)
End Sub

function MemberMachWasAnderes (X as Integer) As String
  MemberMachWasAnderes = ExtMachWasAnderes(X)
End Funcition

End Class


'****

sub ExtMachIrgendwas (Param As String)
  REM Hier der effektive Code
End Sub


'****

function ExtMachWasAnderes (X as Integer) As String
   ExtMachWasAnderes = "Die durchzuführende Berechnung mit X"
End Function

Zitat von: Thomas Völk am 19.06.04 - 03:17:18

warum möchtest du eine Klasse haben? Du hast ja scheinbar schon etwas funktionierendes in deiner History-Scriptlibrary...

Sehr berechtigte Frage, ich glaube ich werde es dabei lassen. Die Subs/Functions, die ich ausschließlich in dieser ScriptLib verwende, mache ich noch zu "Private", dokumentiere das ganze in den Declarations, und dann sollte das gut so sein.

Mein Ziel war, etwas dabei zu lernen. Aber ich denke das gehe ich mal neu an bei einem anderen passenden Projekt.

Ich denke, du kannst auch was lernen, wenn du ein objektorientiertes History-Framework entwickelst.
Meine Frage sollte nicht bewirken, dass du einen Rückzieher machst. Ich wollte wirklich nur wissen, warum - und 'lernen' ist schon ein ziemlich guter Grund.

Also nochmal: der erste Schritt ist, aufzuschreiben, was das Ding alles können soll. Los gehts...

OK, was ich der Bible von Rocky und Brian entnommen habe, ist das schon mal ein must-have in jeder Klasse:

ok.
vorneweg: als geschickt würde ich es empfinden, midestens zwei Klassen zu erstellen:
Klasse History
Klasse HistoryEntry

wobei HistoryEntry eine abstrakte Klasse ist und als Basisklasse für zwei andere Klassen dient:
Klasse RTFHistoryEntry
Klasse TextHistoryEntry

(abstrakte Klasse bedeutet, dass von dieser Klasse nie eine Instanz/ ein Objekt erzeugt wird. Basisklasse bedeutet, dass von ihr andere Klassen abgeleitet sind, die ihre Methoden und Attribute erben)

in der Praxis könnte das dann so aussehen, dass ein History-Objekt ermittelt, welcher Eintrag (Text oder RTF) erzeugt werden muss.
Das kann es z.B. anhand eines Feldwerts oder der Präsenz bzw. Absenz eines Felds im Notesdokument entscheiden.
Das History-Objekt erzeugt dann ein entsprechendes HistoryEntry-Objekt und übergibt diesem die Daten, die es enthalten soll.
Das HistoryEntry-Objekt kennt das Notesdokument und weiß, wie es sich ins darin verewigen muss (also entweder als RTF oder als Text).

Ich würde das für den Anfang einfacher halten. EINE Klasse, und diese
- wird in den Declarations der Form instantiiert
- New löst entweder das Belegen der zu überwachenden Felder im Originalzustand aus oder es wird mit einer eigenen Methode der Klasse diese Belegung aufgerufen (auf jeden Fall: Ein Array der zu überwachenden Feldnamen wird an New übergeben)
- Ein Compare/Write History vergleicht und schreibt dann das History field.

Das Ganze kann man dann ja beliebig ausbauen  

Bernhard

Zitat von: TMC am 20.06.04 - 16:41:13

Wo es imho schon mal hängt ist, dass ich im Postopen-Event was in eine (in der Maske definierten) globalen Variable schreibe, worauf ich im Postsave wieder zugreifen will. Kann ich das in der Klasse machen oder muss ich das direkt im Postopen/Postsave machen?

Du kannst die Behandlung von Events, die von der Maske ausgelöst werden, an die Klasse delegieren (das steht auch in dem Artikel, den Bernhard anführt).

Stichwort 'On Event x From y Call z'

Hier als Beispiel dazu ein Ausschnitt aus einer Klasse
Im QueryOpen-Event des Dokuments wird ein Objekt dieser Klass erzeugt. Alle für mich interessanten Events, die danach ausgelöst werden, werden von diesem Objekt behandelt (das wird in dem Konstruktor (Sub New) festgelegt).

Public Class xyz
   Private m_udFrontendDoc As notesuiDocument
   Private m_docBackendDoc As notesDocument

   Sub New(udCurrentDoc As notesUIDocument)
%REM
------------------------------------------------------------------------------------------------------------------------
Author:      TV
Date:      23.10.2003
Description:   Ich initialisiere meine Attribute und sorge dafür, dass Events aus dem FrontendDocument
         durch mich bearbeitet werden.
Parameter:   udCurrentDoc: NotesUIDocument
            Das Frontend-Dokument, das die Agent-Informationen anzeigt
Return Value:   <Name, Datentyp und Erklärung des Rückgabewertes>
History:      
------------------------------------------------------------------------------------------------------------------------
%END REM   
      
      'Frontend-Dokument und zugehöriges Backend-Dokument besorgen
      Set m_udFrontendDoc = udCurrentDoc
      
      'Achtung! Das BackendDokument ist in normalen Masken erst im Postopen Event verfügbar!
      'In Dialogboxen kann es schon im QueryOpen Event verfügbar sein.
      Set m_docBackendDoc = udCurrentDoc.Document
      
      'auf Events des FrontendDokuments reagieren
      On Event Postopen From m_udFrontendDoc Call ProcessPostopen
      On Event Postrecalc From m_udFrontendDoc Call ProcessPostrecalc
      
      'Zeitgesteuerte Agenten suchen und dem Benutzer zur Auswahl anzeigen
      Call initAgentMap()   
      Call collectScheduledAgents
      Call m_docBackendDoc.ReplaceItemValue(ST_DEFI_AMGR_AvailableAgents, m_asScheduledAgents)
   End Sub

   Sub ProcessPostopen(Source As Notesuidocument)
%REM
------------------------------------------------------------------------------------------------------------------------
Author:      TV
Date:      23.10.2003
Description:   Ich aktualisiere das FrontendDokument
Parameter:   <Name, Datentyp und Erklärung des Übergabeparameters>
Return Value:   <Name, Datentyp und Erklärung des Rückgabewertes>
History:      
------------------------------------------------------------------------------------------------------------------------
%END REM
      Call m_udFrontendDoc.Refresh()
   End Sub

End Class

Was Deine Klassen-Methoden angeht: Du kannst entweder die sowieso erforderliche Methode New dafür hernehmen, um
- alle globalen Variablen (als members Deiner Klasse) mit dem Ausgangsstatus zu versehen (in PostOpen) oder
- dieser erstmal nur "leer" zu instantiieren. Dann müsstest Du in PostOpen gleich nachschieben, die Methode "GetOriginalValues" zu verwenden (die das tun sollte, was ihr Name verspricht)

Du kannst die Behandlung von Events, die von der Maske ausgelöst werden, an die Klasse delegieren (das steht auch in dem Artikel, den Bernhard anführt).
Stichwort 'On Event x From y Call z'

Was mir noch überhaupt nicht klar ist:

Ich habe bisher u.a. folgenden Code in der Maske (Auszüge):

Global Declarations

PostOpen

Was passiert da:
Es werden die zu überwachenden Feldnamen und die Item-Inhalte als Array in die globalen Variablen der Maske gesetzt.
Warum mach ich das:
Im Postsave hole ich mir die globalen Variable-Inhalte und mach was damit (vergleichen, etc.).

Jetzt die Frage:
Was kann ich davon in eine Klasse 'outsourcen' ? Kann ich die in der Maske ge-dim-ten  Variablen in einer Klasse setzen (ich will ja im PostSave wieder auf die im Postopen gesetzten Variablen wieder zurückgreifen können)? Oder muss ich das im Masken-Event erledigen?

(Ich hoffe dass ich die Frage einigermaßen klar rüberbringe....)

Ich habe bisher u.a. folgenden Code in der Maske (Auszüge):

Global Declarations

Code

Dim vGlobalHistoryFields As Variant
Dim vGlobalHistoryFieldTitles As Variant
Dim vGlobalHistorySource As Variant

PostOpen

Code

   vGlobalHistoryFields = fExplode(CHISTORYFIELDS, "##")
   vGlobalHistoryFieldTitles = fExplode(CHISTORYFIELDTITLES, "##")
   If Not Source.IsNewDoc Then
           'Write field values in global variable
      vGlobalHistorySource = fHistoryStoreItemValuesInArray(doc, vGlobalHistoryFields)
   End If

aha, so machst du das. vGlobalHistoryFields sind die Felder, die beobachtet werden sollen, stimmts?
Mein erster Gedanke ist, dass wir hier wieder einen Kandidaten für eine Klasse haben. Ich muss mal kurz nachdenken.
Aber egal, was dabei rauskommt, du solltest das alles aus der Maske rausbringen. Ok, die Information, welche Felder beobachtet werden sollen, kann man evtl. in der Maske lassen, aber keine Logik