Wie kann ich eine Klasse sinnvoll aufbauen ?

[TMC]

Danke, Ulrich.

Wobei: es sind wohl erst gute 50% fertig, viele Feinarbeiten sind noch zu tun und noch ein paar Dinge zu implementieren.

Zum Bug:
Hatte ich vorhin auch gerade entdeckt   (siehe Anmerkung in Antwort 77).

[TMC]

Nochmal zu diesem Bug (Initial-Values werden nicht neu gesetzt nach dem Speichern):

Man könnte den beheben in dem man einfach das History-Objekt neu erstellt beim PostSave in der HistoryMonitorDoc-Klasse:


Ist imho aber nicht sauber.

Hmm, alternativ könnte man die "Private Sub readInitialValues()" der HistoryMain - Klasse aufmachen und zu Public machen, und dann in der HistoryMonitorDoc - Klasse dann folgendes machen:

 Private Sub ProcessPostSave(Source As NotesUIDocument)
         'nach dem Speichern des Dokuments muss die History geschrieben werden
      Call m_History.save()
      'Nun müssen die neuen Werte wieder gesetzt werden.
      Call m_History.ReadInitialValues()
   End Sub

[animate]

funktioniert

zu den Hilfsfunktionen:
Explode und ErrorHandler sind Kandidaten für eine 'Hilfsfunktions-Bibliothek'

die anderen haben alle was mit Feldern zu tun (gib mir Werte, zeig mir Unterschiede, ...) damit haben wir einen neuen Kandidaten für eine Klasse 'Feld'. die all diese Funktionalität zur Verfügung stellt.

Eine Frage jenseits von OO:
welchen Grund hat es, dass du die Namen der Felder, die überwacht werden sollen, in einem String hältst und nicht in einer Liste/Array/...?

[animate]

Nochmal zu diesem Bug (Initial-Values werden nicht neu gesetzt nach dem Speichern):

Man könnte den beheben in dem man einfach das History-Objekt neu erstellt beim PostSave in der HistoryMonitorDoc-Klasse:


Ist imho aber nicht sauber.

Hmm, alternativ könnte man die "Private Sub readInitialValues()" der HistoryMain - Klasse aufmachen und zu Public machen, und dann in der HistoryMonitorDoc - Klasse dann folgendes machen:

 Private Sub ProcessPostSave(Source As NotesUIDocument)
         'nach dem Speichern des Dokuments muss die History geschrieben werden
      Call m_History.save()
      'Nun müssen die neuen Werte wieder gesetzt werden.
      Call m_History.ReadInitialValues()
   End Sub

du hast die neuen Werte ja schon. du müsstest nur sowas hier in deiner History-Klasse machen, nachdem der Eintrag gemacht wurde:

m_vaInitialFieldValues = m_SavedFieldValues

[TMC]

zu den Hilfsfunktionen:
Explode und ErrorHandler sind Kandidaten für eine 'Hilfsfunktions-Bibliothek'

Hmm, stimmt. Ziel ist allerdings für mich hier, die Klassen per Copy'n'Paste in beliebigen DB's einzusetzen (auch wenn diese sonst keine Klassen haben). Aber vielleicht macht man da dann einfach eine "HistoryHilfsfunktionen" - Lib, die dann immer mitkopiert wird... ?!

die anderen haben alle was mit Feldern zu tun (gib mir Werte, zeig mir Unterschiede, ...) damit haben wir einen neuen Kandidaten für eine Klasse 'Feld'. die all diese Funktionalität zur Verfügung stellt.

Ah ja..... gute Idee :-)

Eine Frage jenseits von OO:
welchen Grund hat es, dass du die Namen der Felder, die überwacht werden sollen, in einem String hältst und nicht in einer Liste/Array/...?

In Konstanten (hier: Global Declarations der Maske) sind leider Arrays nicht möglich afaik. Daher schreibe ich die dort in ein String mit Trennzeichen "##", übergebe diese dann an das Objekt "HistoryMonitorDoc", von da aus weiter an das "HistoryMain"-Objekt und im HistoryMain-Objekt wandle ich die dann in ein Array um (mittels der ExtExplode - Function):

Code

   Private Sub getHistoryFields(strNames As String, strTitles As String)
      'die zu prüfenden Felder ermitteln
      m_vaHistoryFields = ExtExplode(strNames, "##")
      m_vaHistoryFieldTitles = ExtExplode(strTitles, "##")

Bin da aber aufgeschlossen, wenn Du 'ne bessere Idee zur Umsetzung hast :-)

[TMC]

Nochmal zu diesem Bug (Initial-Values werden nicht neu gesetzt nach dem Speichern):
(....)

du hast die neuen Werte ja schon. du müsstest nur sowas hier in deiner History-Klasse machen, nachdem der Eintrag gemacht wurde:

m_vaInitialFieldValues = m_SavedFieldValues

Jo mei, Du hast natürlich Recht, so geht's:

Code

   Private Sub writeHistory()
     'Werte vergleichen und Ergebnisse an den HistoryEntry geben
      m_HistoryEntry.Action = m_vDifferences
      'History-Eintrag ins Dokument schreiben
      Call m_HistoryEntry.write(m_doc)
      'Neue Werte in das InitialValue-Array schreiben, für den Fall dass erneut gespeichert wird
      m_vaInitialFieldValues = m_SavedFieldValues
   End Sub

[animate]

In Konstanten (hier: Global Declarations der Maske) sind leider Arrays nicht möglich afaik. Daher schreibe ich die dort in ein String mit Trennzeichen "##", übergebe diese dann an das Objekt "HistoryMonitorDoc", von da aus weiter an das "HistoryMain"-Objekt und im HistoryMain-Objekt wandle ich die dann in ein Array um (mittels der ExtExplode - Function):

Code

   Private Sub getHistoryFields(strNames As String, strTitles As String)
      'die zu prüfenden Felder ermitteln
      m_vaHistoryFields = ExtExplode(strNames, "##")
      m_vaHistoryFieldTitles = ExtExplode(strTitles, "##")

Bin da aber aufgeschlossen, wenn Du 'ne bessere Idee zur Umsetzung hast :-)

naja, die Frage ist, ob wir hier Konstanten einsetzen müssen.
Ich sehe das so: String-Konstanten setze ich ein, wenn ich die Zeichenfolge, die sie darstellen, an 1-n Stellen verwenden müsste. So vermeide ich Tippfehler und ich kann einen Wert an einer Stelle ändern und das hat Auswirkungen auf alle Stellen, wo dieser Wert verwendet wird.

In diesem Fall käme in meinen Augen die "Befüllung" einer Liste mit den Feldnamen der Deklaration einer Konstanten gleich. (Und ich würde mir damit das hantieren mit irgendwelchen Trennzeichen sparen )
Aber das ist Geschmackssache.

[TMC]

naja, die Frage ist, ob wir hier Konstanten einsetzen müssen.
Ich sehe das so: String-Konstanten setze ich ein, wenn ich die Zeichenfolge, die sie darstellen, an 1-n Stellen verwenden müsste. So vermeide ich Tippfehler und ich kann einen Wert an einer Stelle ändern und das hat Auswirkungen auf alle Stellen, wo dieser Wert verwendet wird.

In diesem Fall käme in meinen Augen die "Befüllung" einer Liste mit den Feldnamen der Deklaration einer Konstanten gleich. (Und ich würde mir damit das hantieren mit irgendwelchen Trennzeichen sparen )
Aber das ist Geschmackssache.

An welchem Ort würdest Du das denn machen? Im Postopen der Maske?

Ich habe ja auch schon hin- und herüberlegt......

Auf die History-Klasse(n) wird man wohl dann von mehreren Seiten zugreifen
A) Wie hier umgesetzt über Postopen der Maske
B) Beispielsweise in einer Workflow-Anwendung, wo man dann z.B. eine Statusänderung reinschreibt wie "Approved document." oder so.

Problem: Wo lege ich z.B. zentral fest, wie viele Einträge die History überhaupt haben darf?
Entweder macht man das imho in der Klasse - oder aber via Setup-Dokument. Welches sich ja auch für die Definition der zu überarbeitenden Feldern anbieten würde.

[TMC]

Nochmal zum Errorhandling:

Hab grad sowas versucht:

Code

Public Class HistoryMain
   
   On Error goto ErrorHandler

Dann kommt die Meldung:

HistoryMain: (Declarations): 10: Statement illegal in CLASS block: ON

Heißt das man müsste das Errorhandling in jede Sub/Function der Klasse einzeln schreiben?
Schade....

[animate]

ja, also Setup/Konfigurationsdokument ist immer mein Favorit.
Dann kann da schrauben, ohne an den Code zu müssen.

Wenn ich es im Code machen würde, dann würde ich es in der Maske machen. Wo da genau ist wohl auch Geschmackssache

[TMC]

Hier nun eine neue Version.

Bugs entfernt:
+ o.g. Bug entfernt
+ CStr() eingebaut, damit sollten nun auch Datumsfelder etc. überwachbar sein :-)

Neu:
+ Klasse "HistoryField"
+ ScriptLib "HistoryAuxiliaryRoutines"

Download:
history_02.zip (35 KB)


Kann sich da bitte mal wer die Klasse "HistoryField" anschauen?
Passt die so?

[animate]

ich habe Anmerkung zu der neuen Klasse.

Was du gemacht hast ist, vereinfacht ausgedrückt, die Funktionen gepackt, in eine Bibliothek gepackt und 'Class' drum herum geschrieben.

Das ist nix Schlimmes, nur ist das nicht so ganz das, was ich mir vorgestellt habe, als ich schrieb, wir brauchen eine Feld-Klasse, und das ist ja auch nicht schlimm.

Da wir hier aber in einem Thread sind, in dem es darum geht, wie man geschickt objektorientiert analysiert, entwirft und programmiert, versuche ich zu erklären, was ich beim Schreiben im Kopf hatte.
Ein Objekt der Klasse 'Feld' repräsentiert genau ein zu überwachendes Feld aus dem Notesdokument. D.h., wenn ich drei Felder überwachen will, dann brauche ich drei Objekte. Jedes Objekt kann mir Auskunft darüber geben, welchen Wert 'sein' Feld hat, welchen es ürsprünglich hatte bzw. worin der Unterschied zwischen den beiden Werten besteht.
Unser History-Objekt müsste alle Feld-Objekte instanziieren und würde so alle kennen. Wenns dann zum schreiben der Änderungen geht, frägt das History-Objekt der Reihe nach seine Feld-Objekte nach ihren Änderungen und gibt die Ergebnisse an das HistoryEntry-Objekt oder evtl. noch besser, sie übergibt die Feld-Objekte an das History-Entry-Objekt und das fragt selbst nach.

Wir könnten hier das gleiche Prinzip anwenden, wie ich bei der HistoryEntry-Klasse vorgeschlagen habe, also eine abstrakte Basisklasse 'Feld' und davon abgeleitete Klassen 'Textfeld' und 'RTFFeld'
(ich hab da in deinem Code irgendwas mit "I AM RTF" gesehen, ich weiß zwar nicht genau, wofür das ist, aber evtl. könnte man sowas durch solche Subklassen umgehen...)

[animate]

ist der Unterschied zwischen den beiden Varianten klar? Wenn nicht, dann einfach nachfragen

[TMC]

Was du gemacht hast ist, vereinfacht ausgedrückt, die Funktionen gepackt, in eine Bibliothek gepackt und 'Class' drum herum geschrieben.

Stimmt, genau das habe ich gemacht  

Ein Objekt der Klasse 'Feld' repräsentiert genau ein zu überwachendes Feld aus dem Notesdokument. D.h., wenn ich drei Felder überwachen will, dann brauche ich drei Objekte. Jedes Objekt kann mir Auskunft darüber geben, welchen Wert 'sein' Feld hat, welchen es ürsprünglich hatte bzw. worin der Unterschied zwischen den beiden Werten besteht.
Unser History-Objekt müsste alle Feld-Objekte instanziieren und würde so alle kennen. Wenns dann zum schreiben der Änderungen geht, frägt das History-Objekt der Reihe nach seine Feld-Objekte nach ihren Änderungen und gibt die Ergebnisse an das HistoryEntry-Objekt oder evtl. noch besser, sie übergibt die Feld-Objekte an das History-Entry-Objekt und das fragt selbst nach.

Das habe ich glaub ich soweit verstanden. Klingt auch sehr sinnvoll und praktikabel.

Wie würdest Du denn die Feld-Objekte erzeugen? Über eine Schleife? Das ist mir noch nicht ganz klar. Man kann ja z.B. nur 1 Feld zur Überwachung haben oder vielleicht auch 100 (worst case).

Wir könnten hier das gleiche Prinzip anwenden, wie ich bei der HistoryEntry-Klasse vorgeschlagen habe, also eine abstrakte Basisklasse 'Feld' und davon abgeleitete Klassen 'Textfeld' und 'RTFFeld'
(ich hab da in deinem Code irgendwas mit "I AM RTF" gesehen, ich weiß zwar nicht genau, wofür das ist, aber evtl. könnte man sowas durch solche Subklassen umgehen...)

Das "I_AM_RTF" ist bisher so ein Workaround. Wenn das Feld vom Typ RTF ist, dann wird "I_AM_RTF" + Änderungsdatum in ein Array geschrieben; wenn nicht RTF, dann eben der Feldinhalt. Dadurch wird dann beim Zusammensetzen des Actions-Textes erkennbar, was man dort reinschreibt ("Changed RTF...." oder "Changed Field.... former value was ....")

[animate]

Klar, in einer Schleife. Im Konstruktor der History-Klasse.
Da, wo jetzt das steht

      If m_strTextNew = "" Then 'Nur wenn es sich nicht um ein neues Doc handelt
         Call getHistoryFields(m_strHistoryFieldNames, m_strHistoryFieldTitles)
         Call readInitialValues()
      End If

Möglichkeit:
du übergibst dem Konstruktor die Liste mit den Feldnamen und der Konstruktor ruft dann eine Methode zum Erzeugen der Field-Objekte auf (oder machts selber, musst mal schaun)
Die Objekte würden dann die beiden Arrays (Initial und SavedValues) ersetzen.

Was mir gerade einfällt:
Ähnlich wie dein Dokument-Objekt eine Assoziation zum entsprechenden NotesUIDocument-Objekt hat (m_uidoc) könnte jedes Feld-Objekt eine Assoziation zum entsprechenden NotesItem-Objekt haben

[TMC]

OK danke, in der Theorie hab ich das soweit kapiert, mal sehen ob ich das auch so umsetzen kann.  

[animate]

@Thomas: Verate uns ungewaschenen Massen den Trick, wie man in HistoryEntry die Factory implementiert , um das Strategy-Pattern für die Subklassen zu implementieren.
oder schickt mir eine nsf, wenn es für euer Zeugs bisher eine Implementierung aka Beispieldatenbank gibt.

ist die Frage eigentlich noch offen?
ich weiß nicht genau, was du mit 'Trick' meinst, Axel.
Da ist kein Trick. In dem Beispielcode, den ich gepostet habe, habe ich völlig offen gelassen, wie entschieden wird, welches spezielle Objekt erzeugt wird. Möglichkeiten sind z.B. Felder/Feldwerte im betroffenen Dokument, irgendwelche Konfigurationsdokumente, etc.

Frag einfach nochmal, wenn ich die Frage nicht zufriedenstellend beantwortet habe.

[TMC]

Ich bin übrigens gerade dabei, eine Logik einzubauen, um diese blöde Textfeld-Größenbeschränkung zu überwachen.
Nicht dass wer meint ich wäre mittlerweile eingeschlafen :-) (na ja, im Rahmen von MultiTasking mach ich auch nebenbei noch andere Dinge, hab ja auch parallel noch die Book-Rezension gemacht )

Code

   Private Sub removeEntries()
      'Ziel ist es die Größenbeschränkung von Textfeldern zu beachten.
      'Zusätzlich kann der History-Klasse eine Max-Anzahl Einträge übergeben werden.
      'Wenn Max-Anzahl = "", dann wird gleich die Größenüberprüfung eingeleitet.
      'Wenn Max-Anzahl vorgegeben, dann wird erst mal gekürzt und der neue Wert
      'angehängt. Wenn immer noch zu lang: Solange alte Einträge rauswerfen, bis es passt.

While-Wend Schleifen, eine "DeleteArrayPosition"-Function etc. sind dabei hilfreich....

[animate]

ich habs bis jetzt weggelassen, weil ich nicht übertreiben wollte und weils auch nicht nötig war. An dieser Stelle passt es vielleicht.

wir haben ja von History zu HistoryEntry eine 1:n - Beziehung, d.h. zu einem History-Objekt können mehrere HistoryEntry-Objekte gehören.

Im Code würde das so aussehen (in der Klasse History):

Private m_HistoryEntries() As HistoryEntry

also hätten wir ein Array voll mit Objekten anstelle des einen Objekts, das wir jetzt haben.
Denkbar wäre zur Lösung deines Problems folgendes zu tun:
Ein HistoryEntry-Objekt kennt die Größe seines Texts im Notesdokument und  stellt diese Information auch anderen Objekten zur Verfügung (über get-Methode)
Im Konstruktor des History-Objekts (oder in einer Methode, die von dort aus aufgerufen wird) erzeugen wir für jeden Eintrag im Dokument ein HistoryEntry-Objekt und fügen es unserem Array (m_HistoryEntries, s. oben) hinzu.
Beim Speichern des Dokuments wird wie bisher ein HistoryEntry-Objekt erzeugt, das die aktuellen Änderungen repräsentiert und dem Array hinzugefügt.
Wir haben jetzt also alle HistoryEntry-Objekte in unserem Array, und können bevor wir sie ins Dokument schreiben jedes HistoryEntry-Objekt fragen, wie groß es ist, und mit dieser Information entscheiden, wie viele Einträge wir machen.

Nur ne Idee. Einigermaßen verständlich?

[TMC]

Nur ne Idee. Einigermaßen verständlich?

Leider nicht ganz.
Liegt wohl auch an meinem etwas anderen Ansatz.

Hab mir das so gedacht:
Völlig egal ist erstmal, wieviele Zeilen im History-Feld aktuell sind. Jedenfalls passiert irgendwas (User klickt einen Workflow-Button an, oder User öffnet das Dok und will es nach Änderungen speichern) - dadurch wird ein HistoryEntry - Objekt erstellt. Dem Objekt werden dann die Änderungen übergeben (hier als Property), z.B. "habe Antrag genehmigt" oder aber "Feld ABC geändert; alter Wert war "bla bla"". Die Klasse managed den Rest: Wird durch das Ergänzen der neuen Zeile irgend ein Limit überschritten, dann werfen wir den ersten Eintrag raus. Immer noch überschritten: dann fliegt auch der nächste Eintrag raus. While...wend.
Na ja, wie auch immer, habe dank While...wend hier gerade eine Endlosschleife die ich noch flicken muss  

Ich sehe jetzt nicht ganz die Erfordernis das noch zu splitten. Aber es ist auch schon spät. Kann sein dass ich das erst nach ein paar Stunden Schlaf kapiere...