Domino 9 und frühere Versionen > Entwicklung

Wie kann ich eine Klasse sinnvoll aufbauen ?

<< < (19/41) > >>

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:

--- Zitat von: Thomas Völk am 26.06.04 - 19:58:56 ---Was du gemacht hast ist, vereinfacht ausgedrückt, die Funktionen gepackt, in eine Bibliothek gepackt und 'Class' drum herum geschrieben.
--- Ende Zitat ---
Stimmt, genau das habe ich gemacht  ;D


--- Zitat von: Thomas Völk am 26.06.04 - 19:58:56 ---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.
--- Ende Zitat ---
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).


--- Zitat von: Thomas Völk am 26.06.04 - 19:58:56 ---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...)
--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete