Wie kann ich eine Klasse sinnvoll aufbauen ?

[animate]

das könnte jetzt etwas wirr werden, aber wenn wir damit jetzt schon anfangen, dann machen wir das gleich gescheit.
Ich hab mal das Klassendiagramm mit UML gemalt. Das ist einfach der Standard, um sowas zu modellieren. Das Diagramm hängt als Attachment hier dran.

Die Kästen sind Klassen (im Moment noch ohne Methoden/Attribute).
Ganz oben in jedem Kasten steht der Klassenname, gefolgt von den Attributen und den Methoden.
Kursiv geschrieben Klassennamen bedeuten, die Klasse ist abstrakt (von ihr wird keine Instanz erzeugt).
Die Linien mit den großen Pfeilen am Ende heißen Genrealisierung ('ist ein')
Die Linien ohne Pfeile sind ungerichtete Assoziationen ('gehört zu', 'hat')
Die Zahlen, die bei diesen Assoziationen stehen sind die Kardinalitäten  (bestimmt bekannt aus ERD. 'Zu einem History-Objekt gehören n HistoryEntry-Objekte)

Danke für die Tipps und die Zeichnung.
Wo "malt" man sowas am besten? Ich habe hier MS Visio 2002. Na ja, ist damit sicherlich machbar. Werde mir mal ein paar Visio-Shapes dafür zusammenzimmern (wenn diese nicht eh schon dabei sind).

sind normalerweise schon dabei. bei uns auf der Webseite kann man sich auch welche runterladen

[TMC]

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

vGlobalHistoryFields ist sehr unglücklich gewählte Bezeichnung, sollte besser heissen "vGlobalHistoryFieldValues". Das sind die Item-Inhalte.
"vGlobalHistoryFieldTitles" sind die Namen der Items/Felder, die überwacht werden sollen.

Zur eigentlichen Frage: Kann ich eine globale Masken-Variable von einer Klasse aus setzen oder muss ich das im Masken-Event (hier: PostOpen) erledigen? Ziel ist ja, dass ich in einem anderen Masken-Event (Postsave) wieder auf die Werte zurückgreifen kann.

[animate]

die globale Maskenvariable wird zum Attribut (Property) der Klasse

Class x
   Private m_vaValues as Variant

   Public Property Set Values as Variant
      m_vaValues = Values
   End Property

   Public Property Get Values as Variant
      Values = m_vaValues
   End Property


End Class

(weiß nicht, ob das mit den Get/Set-Funktionen syntaktisch so korrekt ist)

dann hast du die Werte für die Lebenszeit deines Objekts zur Verfügung

[TMC]

sind normalerweise schon dabei.

Stimmt  

[TMC]

die globale Maskenvariable wird zum Attribut (Property) der Klasse

Class x
   Private m_vaValues as Variant

   Public Property Set Values as Variant
      m_vaValues = Values
   End Property

   Public Property Get Values as Variant
      Values = m_vaValues
   End Property


End Class

(weiß nicht, ob das mit den Get/Set-Funktionen syntaktisch so korrekt ist)

dann hast du die Werte für die Lebenszeit deines Objekts zur Verfügung

Wann ist denn mein Objekt tot?
Ich dachte, es ist z.B. dann tot, wenn das "End Sub" z.B. vom PostOpen-Event aufgerufen wird? Oder überlebt dies das Objekt?

[animate]

kommt drauf an, wo du es deklarierst.
wenn du es im Sub Postopen deklarierst, ist es danach tot.

wenn du es in den Declaration der Maske deklarierst und im Postopen erzeugst, dann hast du es bis zum Terminate-Event der Maske

[TMC]

Wann ist denn mein Objekt tot?

Ich kenne das auch aus anderem Kontext. Manchmal ist sowas hilfreich:
Set uidoc = Nothing
Da ansonsten u.U. ein anderes UI-Document im Fokus ist unter bestimmten (nicht immer nachvollziehbaren) Umständen - und somit das Objekt nicht 'tot' ist.....

[TMC]

kommt drauf an, wo du es deklarierst.
wenn du es im Sub Postopen deklarierst, ist es danach tot.

wenn du es in den Declaration der Maske deklarierst und im Postopen erzeugst, dann hast du es bis zum Terminate-Event der Maske

Jetzt geht mir langsam ein Licht auf

Ich muss verdammt nochmal meine Denkweise umstellen  

[TMC]

cool, Visio bietet da schon sehr viel, hier ein Update meines Modells (vieles fehlt noch, ist erstes Experiment):


Was mir viel Spaß macht ist die logische Vorgehensweise. Kein Durcheinander. Alles strukturiert und logisch.

[animate]

ich hab mal ein Gerüst zusammengezimmert, das wir zur Diskussion verwenden können.
hier kommts:

Maske
'Options
Use "Document"
Option Declare
'Declarations
Dim myDoc as Document

Sub Postopen(Source As Notesuidocument)
   Set myDoc = New Document(source)
End Sub

Klasse Document
Option Declare
Use "History"
Public Class Document
   
   Private m_uidoc As NotesUIDocument
   Private m_doc As NotesDocument
   Private m_History As History
   
   Public Sub new (uidoc As NotesUIDocument)
      'initialisieren
      Set m_uidoc = uidoc
      Set m_doc = uidoc.Document
      Set m_History = New History(m_doc)
      On Event PostSave From m_uidoc Call ProcessPostSave   
   End Sub
   
   
   Private Sub ProcessPostSave(Source As NotesUIDocument)
      'nach dem Speichern des Dokuments muss die History geschrieben werden
      Call m_History.save()
   End Sub
End Class


Klasse History
Option Declare
Use "HistoryEntry"
Use "TextHistoryEntry"

Public Class History
   Private m_doc As NotesDocument
   Private m_vaHistoryFields As Variant
   Private m_InitialFieldValues As Variant
   Private m_SavedFieldValues As Variant
   Private m_HistoryEntry As HistoryEntry
   
   Public Sub new(doc As NotesDocument)      
      Set m_doc = doc
      
      'Ermitteln, welche Felder beobachtet werden sollen und die Werte der Felder einlesen
      Call getHistoryFields()
      Call readInitialValues()
      
      'Ermitteln, welche HistoryEntry-Art erzeugt werden muss
      
      '...Ich tu so, als ob ich ermittelt hätte, dass ich normalen Text schreiben muss
      Set m_HistoryEntry = New TextHistoryEntry
      '...
   End Sub
   
   Public Sub save()
      'die einzige Funktion, die nach aussen sichtbar ist
      Call readSavedValues()
      Call writeHistory()
   End Sub
   
   Private Sub getHistoryFields()
      'die zu prüfenden Felder ermitteln
      'zur Einfachheit mache ich hier feste Werte
      'denkbar wäre, die Feldnamen in einem Konfigurationsdokument zu halten und hier auszulesen
      Redim m_vaHistoryFields(0)
      m_vaHistoryFields(0) = "Subject"
   End Sub
   
   Private Sub readInitialValues()
      'die Anfangswerte lesen
      Dim i As Integer      
      Redim m_InitialFieldValues(Ubound(m_vaHistoryFields))
      For i = 0 To Ubound(m_vaHistoryFields)
         m_InitialFieldValues(i) = m_doc.GetItemValue(m_vaHistoryFields(0))
      Next
   End Sub
   
   Private Sub readSavedValues()
      'die gespeicherten Werte lesen
      Dim i As Integer      
      Redim m_SavedFieldValues(Ubound(m_vaHistoryFields))
      For i = 0 To Ubound(m_vaHistoryFields)
         m_SavedFieldValues(i) = m_doc.GetItemValue(m_vaHistoryFields(0))
      Next
   End Sub
   
   Private Sub writeHistory()
      'Werte vergleichen und Ergebnisse an den HistoryEntry geben
      'ich lasse zur Einfachheit die Logik fürs Vergleichen weg und nehme feste Einträge
      m_HistoryEntry.myDate = "20.06.2004"
      m_HistoryEntry.myName = "TV"
      m_HistoryEntry.myAction = "saved"
      
      'Eintrag ins Dokument schreiben
      Call m_HistoryEntry.save(m_doc)
   End Sub
End Class

Klasse HistoryEntry

Option Declare

Public Class HistoryEntry
   
   'ein Eintrag besteht immer aus drei Daten
   Private m_sDate As String
   Private m_sName As String
   Private m_sAction As String
   
'Get/Set-Methoden
   Public Property Set myDate As String
      m_sDate = myDate
   End Property
   Public Property Set myName As String
      m_sName = myName
   End Property
   
   Public Property Set myAction As String
      m_sAction = myAction   
   End Property
   Public Sub new()
      
   End Sub
   
   
   
   Public Sub save(doc As NotesDocument)
      'ich werde von den speziellen Klassen implementiert
      'sie wissen genau, wie das speichern aussieht.
   End Sub
End Class


Klasse TextHistoryEntry

Option Declare
Use "HistoryEntry"
Const FIELD_NAME = "Name"
Const FIELD_DATE = "Date"
Const FIELD_ACTION = "Action"

Public Class TextHistoryEntry As HistoryEntry
   
   
   Public Sub new()
      
   End Sub
   
   Public Sub save(doc As NotesDocument)
      'neuen Eintrag schreiben
      'zur Einfachheit überschreibe ich hier die aktuellen Werte
      'normalerweise müssen sie angehängt werden
      Call doc.ReplaceItemValue(FIELD_NAME, m_sName)
      Call doc.ReplaceItemValue(FIELD_DATE, m_sDate)
      Call doc.ReplaceItemValue(FIELD_ACTION, m_sAction)
      Call doc.Save(True, True)
   End Sub
   
End Class

was fehlt ist die Klasse für die RTF-History, aber es müsste klar sein, wie die zu machen ist.

bin gespannt, was ihr davon haltet. wie gesagt, das ist nur ein Diskussionsstartpunkt, ich behaupte nicht, dass das gut oder schlecht ist.

[TMC]

cool, danke für Deinen Einsatz, Thomas  

Wir sind imho eigentlich schon mittendrin, im - von Jens ursprünglich geplanten - OO-Kurs  

Schau mir das gleich mal an....

[animate]

cool, danke für Deinen Einsatz, Thomas  

Wir sind imho eigentlich schon mittendrin, im - von Jens ursprünglich geplanten - OO-Kurs  

Schau mir das gleich mal an....

kein Problem. Kann ich ja vielleicht sogar mal brauchen.

Ja, wir sind mitten in sowas drin, aber vermutlich nicht so, wie sich Jens das von didaktischer Seite her vorgestellt hat. Aber vielleicht ist es so auch nicht allzu schlecht, auch wenns etwas konfus ist.
Immerhin hast du mittlerweile schon drauf, wie man ein Klassendiagramm mit den notwendigsten Elementen malt. Das ist nicht das Schlechteste.

[TMC]

Ja, wir sind mitten in sowas drin, aber vermutlich nicht so, wie sich Jens das von didaktischer Seite her vorgestellt hat. Aber vielleicht ist es so auch nicht allzu schlecht, auch wenns etwas konfus ist.
Immerhin hast du mittlerweile schon drauf, wie man ein Klassendiagramm mit den notwendigsten Elementen malt. Das ist nicht das Schlechteste.

Jo, etwas konfus das ganze. Hat sich wohl eben aufgrund meiner Anfrage so ergeben....  

Hab hier mal den Code von Dir in eine R5 - DB kopiert (see attached)

[TMC]

Noch eine Grundsatzfrage zu Public / Private:

Man nehme eine ScriptLibrary:

Per Default steht dort in den Options "Option Public".
Wenn ich dort eine Function erstelle, ist diese öffentlich verfügbar, sprich wenn ich ein Use "MeineScriptLib" in einer Maske einbaue, habe ich Zugriff auf die Routine.

Wenn ich eine Sub/Function mit "Private Sub...." oder "Private Function..." einleite, dann kann ich darauf nur in der ScriptLib zugreifen.

So kenn ich das zumindest.
Jetzt würde mich interessieren wie das umgekehrt ist:
Wenn da kein "Option Public" steht, ist die ScriptLib gar nicht verfügbar? Muss dann da "Option Private" stehen oder ist ein fehlendes "Option Public" automatisch ein "Option Private" ? Was ist wenn dann eine Sub/Function mit "Public Sub..." eingeleitet wird, ist diese dann auch z.B. in einem Masken-Event verfügbar (obwohl in den ScriptLib-Options nix steht oder "Option Private") ?

Ich habe wohl grad den Fehler gemacht, "Option Public" in den Script Libs stehen zu lassen, als ich Thomas' Code hineinkopierte.... (bin mir aber nicht sicher ob das relevant ist...)

[TMC]

Was mir gerade eben auffällt in Deinem Code, Thomas:

Rocky Oliver schreibt in seiner "Bible", das alle Klassen immer eine "Delete sub" enthalten sollen, die vermisse ich hier jetzt.

Ich kann allerdings mangels Know-how nicht abschätzen, wie wichtig das ist .......

[animate]

Hab hier mal den Code von Dir in eine R5 - DB kopiert (see attached)

ah, läuft. schon mal näher im Debugger angeschaut, was da abläuft?

im Prinzip sehr simpel.
beim Öffnen eines Notesdokuments erzeugst du ein Dokument, das Dokument erzeugt eine History, die History erzeugt einen HistoryEntry
nach dem Speichern sagt das Dokument zur History 'speicher dich', die gibt den Befehl an den HistoryEntry weiter und der schreibt die benötigten Informationen ins NotesDokument.

Jetzt die Erklärung, warum ich es geschickter finde, eine abstrakte HistoryEntry-Klasse und mehrere davon abgeleitete Klassen zu verwenden.

was passiert, wenn von uns eine dritte Art gefordert wird, eine Historie zu schreiben.
an meiner funktionierenden History-Klasse füge ich genau zwei Zeilen hinzu (switch/select - Statement)
und ich erstelle eine neue Klasse für die geforderte dritte Art.
Der Rest meiner Klassen bleibt auf jeden Fall unberührt und muss z.B. nicht nochmal getestet werden, was evtl der Fall bei nur einer Klasse wäre.
Wenn jetzt noch mehr History-Arten verlangt werden, kein Problem. Der Code bleibt klein und übersichtlich. Bei nur einer Klasse könnte es etwas unübersichtlich werden.

Eine Klasse für das alles wäre vollkommen ok gewesen, für sich ändernde Anforderungen aber vielleicht unflexibler als die Variante mit mehreren Klassen.
Ich hoffe, ihr versteht, was ich meine.

[animate]

Noch eine Grundsatzfrage zu Public / Private:

Man nehme eine ScriptLibrary:

Per Default steht dort in den Options "Option Public".
Wenn ich dort eine Function erstelle, ist diese öffentlich verfügbar, sprich wenn ich ein Use "MeineScriptLib" in einer Maske einbaue, habe ich Zugriff auf die Routine.

Wenn ich eine Sub/Function mit "Private Sub...." oder "Private Function..." einleite, dann kann ich darauf nur in der ScriptLib zugreifen.

So kenn ich das zumindest.
Jetzt würde mich interessieren wie das umgekehrt ist:
Wenn da kein "Option Public" steht, ist die ScriptLib gar nicht verfügbar? Muss dann da "Option Private" stehen oder ist ein fehlendes "Option Public" automatisch ein "Option Private" ? Was ist wenn dann eine Sub/Function mit "Public Sub..." eingeleitet wird, ist diese dann auch z.B. in einem Masken-Event verfügbar (obwohl in den ScriptLib-Options nix steht oder "Option Private") ?

Ich habe wohl grad den Fehler gemacht, "Option Public" in den Script Libs stehen zu lassen, als ich Thomas' Code hineinkopierte.... (bin mir aber nicht sicher ob das relevant ist...)

Wenn kein Option Public dasteht ist erstmal alles Private, also nur innerhalb des Moduls sichtbar.

Ich habe mir aus diversen Gründen angewöhnt, das Option Public aus ScriptBibliotheken rauszuschmeißen.
Wenn du das stehen lässt, ist das kein Problem, weil sowieso vor jeder Methode / jedem Attribut Private oder Public steht.

[TMC]

Wenn kein Option Public dasteht ist erstmal alles Private, also nur innerhalb des Moduls sichtbar.

Ich habe mir aus diversen Gründen angewöhnt, das Option Public aus ScriptBibliotheken rauszuscheißen.
Wenn du das stehen lässt, ist das kein Problem, weil sowieso vor jeder Methode / jedem Attribut Private oder Public steht.

Nun geht mir ein weiteres Licht auf  
Ist imho auch ein Thema, was in den "Was ein Notes Entwickler immer beachten sollte" - Thread gut passt.... (natürlich dann mit Erklärung)

[animate]

Was mir gerade eben auffällt in Deinem Code, Thomas:

Rocky Oliver schreibt in seiner "Bible", das alle Klassen immer eine "Delete sub" enthalten sollen, die vermisse ich hier jetzt.

Ich kann allerdings mangels Know-how nicht abschätzen, wie wichtig das ist .......

die Methode dient zum Aufräumen.
warum er schreibt, dass man die unbedingt immer braucht, kann ich nicht so recht nachvollziehen.
Sowas braucht man z.B. wenn du bidirektionale Verbindungen zu anderen Objekten hast. Wenn dein Objekt zerstört wird, dann zeigen die Referenzen der anderen Objekte auf dieses Objekt ins Leere, deshalb ist es ratsam solche Verbindungen kurz vor dem Ableben zu lösen.
In unserem Fall sehe ich keine Notwendigkeit, irgendwas aufzuräumen

[TMC]

die Methode dient zum Aufräumen.
warum er schreibt, dass man die unbedingt immer braucht, kann ich nicht so recht nachvollziehen.
Sowas braucht man z.B. wenn du bidirektionale Verbindungen zu anderen Objekten hast. Wenn dein Objekt zerstört wird, dann zeigen die Referenzen der anderen Objekte auf dieses Objekt ins Leere, deshalb ist es ratsam solche Verbindungen kurz vor dem Ableben zu lösen.
In unserem Fall sehe ich keine Notwendigkeit, irgendwas aufzuräumen

Das von Dir hört sich plausibel an.
Rocky schreibt auch nur sehr allgemein und hat das Klassen-Kapitel seeehr kurz gehalten in seinem Buch.
Er schreibt: "(...) Your class requires 2 subs - New (used to create the class) and Delete (used to destroy the class and perform cleanup). (...) all classes should have a New sub and a Delete sub"

Dem Umfang der Bible entsprechend ist eh das Kap. "Creating LS Classes" imho sehr kurz gehalten (vielleicht 1 Seite Text, Rest ist Source Code), mir macht es den Anschein, als ob da schnell mal darüber hinweg gegangen wurde (obwohl das Buch selbst wirklich sehr gut ist).