Domino 9 und frühere Versionen > Entwicklung

Dokumenthistorie / Feldvergleich (vorher/nachher)

<< < (3/5) > >>

koehlerbv:
@TMC:
Solch eine Dokumentenhistorie kann immer wieder gebraucht werden. Ich würde Dir aus eigener Erfahrung empfehlen, hierfür gleich allgemeingültige Routinen zu schreiben:
- In den Declarations ein Array mit den zu überwachenden Feldnamen (ein späteres Erweitern / Reduzieren ist so easy machbar)
- im PostOpen das Auslesen der Ist-Zustände in ein weiteres Array of Variants (wenn DataType = RICHTEXT, dann spezielles Verfahren)
- eine allgemeingültige Routine zum Vergleichen von Notes-Items (wenn DataType = RICHTEXT, dann spezielles Verfahren), der es egal sein muss, welcher Datentyp vorliegt oder ob EMPTY, Scalar oder Array
- eine History-Routine, die die ItemSize des History-Felds überwacht und dieses beschreibt.

Einmal gemacht, ist das dann vielseitig einsetzbar. Lohnt auch, nett in eine Klasse zu kapseln ;-)

Bernhard

eknori:
>> Ein Textfeld

OK, I stimm u 2; aBär look at http://eknori.dyndns.org/knowledge/devidea.nsf/Alpha/0EB33C0ACD4A50248025681F002D517E?OpenDocument

welche Paranoiker sind denn da eigentlich am Werke ...

das sollte doch wohl alles im Rahmen bleiben (können)

TMC:

--- Zitat von: koehlerbv am 01.06.04 - 23:29:02 ---Solch eine Dokumentenhistorie kann immer wieder gebraucht werden. Ich würde Dir aus eigener Erfahrung empfehlen, hierfür gleich allgemeingültige Routinen zu schreiben
--- Ende Zitat ---

Bernhard, Du kannst wohl Gedanken lesen, genau das hatte ich vor   :D

Die Historie selbst schreibe ich übrigens in ein Richtextfeld und nicht in ein Textfeld (mit NotesrichTextParagraphStyle und rt-Kollechen :-)), damit ich eine saubere Formatierung erhalte: http://www.atnotes.de/index.php?board=7;action=display;threadid=14772

Ich will im Prinzip als Endziel
a) eine (nahezu) Copy&Play fähige Lösung auch für andere DB's
b) Null Aufwand haben wenn sich Felder ändern, neu hinzukommen oder entfallen

Und Du hast ja hierzu schon die Vorgehensweise kurz beschrieben - sowas ähnliches hatte ich mir auch schon ausgedacht  :) (wenn auch noch nicht so detailliert - ist in jedem Fall ein guter Anhaltspunkt zum starten !)

koehlerbv:
@Ulrich:
Jo, völlig wahr.
Es kommt immer auf die äusseren Umstände an. Nach denen müssen sich dann die technischen Massnahmen richten.
Meist reicht "fein und knackig"  ;D

Bernhard

koehlerbv:
@TMC:
Nö, Gedanken lesen kann ich nicht. Aber ich hatte eben auch schon die eine oder andere Erfahrung sammeln können bzw. müssen.

By the way: Gerade wegen der Allgemeingültigkeit und der Übersichtlichkeit habe ich mich gegen RTFs als History fields entschieden. Bei mir sind das Textlisten, die über eine Function belegt werden, der ich die Anzahl der erlaubten Einträge mitgebe (dass dabei die max. Grösse eines Textfelds nicht überschritten wird, dafür sorgt die Function selber). Das gibt mir später die Möglichkeit, applikationsspezifisch die History nach bestimmten Stichworten von oben oder von unten zu durchsuchen und darauf wiederum zu reagieren, ohne dabei gleich eine straff "mehrdimensionales" (also "mehrfeldige") History führen zu müssen.

Wenn natürlich jeder "Pups" von Anfang bis Ende protokolliert werden muss und es dabei egal ist, dass die eigentlichen Informationen 2 kB, die History aber 12 MB umfasst - dann muss es ein RTF sein. Ich wünsche Dir aber, dass Du solche Paranoiker nicht im Nacken hast ;-)

Bernhard

PS: Gerade letztens wünschte ein Kunde die History auf drei Einträge beschränkt zu bekommen. Das war dann sogar mir zuwenig, aber des Kunden Wunsch ist sein Himmelreich. Wenn er es sich anders überlegt, muss ich in den Funktionsaufrufen ja nur eine Zahl zu verändern. Und da das eine globale Konstante in diesem Falle ist ... Könnte man ja sogar ins globale Setup-Doc verlegen ;-)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete