gesucht: Log-Liste mit Schlüssel-Wert und Parent pro Eintrag

[raller09]

Moin,

ich brauche mal eure Hilfe/Ideen:

Ich habe eine Log-Liste im Programm, bei der bei verschiedenen Aktionen

• Speichern eines Kunden/Artikels/...
• Änderungen innerhalb einer Liste von Kunden/Artikel/...
• Export von Daten
• Massenänderungen
• ...

Meldungen eingetragen werden. Diese Liste hat auch jeweils Kinder-Einträge mit weiteren Detail-Informationen.

Zur Ausgabe wird daraus ein eingerückter Text erstellt und in einem Text-Fenster angezeigt, der die Hinweis oder Fehler ausgibt:

Kunde 4711

Artikel 0815

Bezeichnung fehlt
VK-Preis 2,45 unter Einstands-Preis

Artikel 666

Gebindegroesse fehlt

Das funktioniert aktuell auch hinreichend gut.
Ich würde dieses Fenster jetzt gerne erweitern auf eine Grid oder Tree-Darstellung, bei der man einzelnen Zeilen anklicken kann, um damit

• den entsprechenden Eintrag in einer Tabelle zu selektieren,
• über die Tabelle in die Detail-Ansicht eines Eintrages zu springen,
• ggf. den Focus auf ein Feld in der Maske zu setzen (muss dann mal sehen, wie weit das dann wirklich ausprogrammiert wird),
• ... .

Dafür sollte es - denke ich - Rückgaben

• als verschiedene Objekt-Klassen oder
• mit Enum-Typen geben,

die dann die entsprechenden Key-Daten zurückliefert:

• Kunden-Nr integer
• ArtikelNr string
• eigener Record record
• FensterControl enum?

Natürlich muss die aufrufende Funktion diese mögliche Rückgaben individuell programmieren/behandeln.
Ich denke also, dass ich bei der Auswahl einer bestimmten Meldung eine Rückgabe in der Art

• TMeldungsKey mit dem Schlüsselfeld für diese Meldung bekomme und
• ggf. ein zusätzliche Parent TMeldungsKey daran hängt, über den ich übergeordnete Elemente behandeln kann.

Nicht für jede Rückgabe wird eine Behandlung umgesetzt + das Parent kann auch mal nil sein...


Habt ihr da mal eine Idee für die Umsetzung der Daten-Einträge und Liste für mich? Gibt es da schon was fertiges (hab mal gesucht aber die Begriffe sind dann doch sehr allgemein...)?
Idee gut oder falsch?


Danke für eure Rückmeldung

[freimatz]

Da fällt mir als erstes VirtualTree ein ... und nach einigem Überlegen ... immer noch VirtualTree.
Es sei denn Du hast spezielle Skin-Design-Anforderungen.

[TurboMagic]

Grundsätzlich geb' ich dir da recht. Nur wird er dann immer noch vor dem Problem stehen,
wie er seine Informationen intern verwaltet... ;-)

[DeddyH]

Als einfachste Möglichkeiten fallen mir da spontan XML oder JSON ein.

[freimatz]

Zitat:

Zitat von TurboMagic (Beitrag 1535973)

Grundsätzlich geb' ich dir da recht. Nur wird er dann immer noch vor dem Problem stehen,
wie er seine Informationen intern verwaltet... ;-)

Hm, da habe ich wohl zu wenig gelesen. Ich ging davon aus, dass er das schon hat.

Zitat:

Zitat von raller09 (Beitrag 1535943)

Ich habe eine Log-Liste im Programm, ...

Wenn nicht dann meine ich: das sind keine sehr schwierige, aber doch schon sehr spezifische Anforderungen. Da gibt es sicher nichts Fertiges. Zur Umsetzung selber bietet Pascal/Delphi alles was man braucht. (einfache Datentypen, Record, Container, Pointer) :-D

[raller09]

Moin,

Zitat:

Zitat von TurboMagic (Beitrag 1535973)

Grundsätzlich geb' ich dir da recht. Nur wird er dann immer noch vor dem Problem stehen,
wie er seine Informationen intern verwaltet... ;-)

genau das ist meine Frage -> konkrete Idee für die interne Datenhaltung.


Hatte gehofft, das bei einem von euch kommt:

Klar, nimm eine generische Klasse mit folgendem Aufbau.
oder: xxx war bei mir nicht flexibel genug.
...

Zitat:

Zitat von DeddyH (Beitrag 1535974)

Als einfachste Möglichkeiten fallen mir da spontan XML oder JSON ein.

Das ist etwas zu Allgemein, oder?


Danke,

[DeddyH]

Nunja, soll ich jetzt eine fertige Lösung präsentieren? In Delphi gibt es ja bereits Serialisierer/Deserialisierer für JSON, die könnte man sich ja einmal anschauen. Sollte einem das nicht genügen, muss man sich halt (ggf. unter Verwendung von jeder Menge RTTI) selbst etwas schreiben. Oder man verzichtet komplett auf ein menschenlesbares Format und baut sich z.B. eine Klassenstruktur auf, bei der jede Klasse in einen (von der obersten Klasse bereitgestellten) Stream schreibt bzw. daraus liest.

[omnibrain]

Intern mit JSON zu arbeiten halte ich für nicht zielführend.
Warum keine Generics-Collections?
Einfach TDictionary<key,value> schachteln.

Eines ist: TArtikellog<Artikelnummer: integer,LogEintraege: TStringlist>
Das andere ist: TKundenlog<Kundennummer: integer,Artikellog: TArtikellog>

Logeinträge kann natürlich auch was komplexeres sein, im Extremfall wieder ein TDictionary)

[himitsu]

XML oder JSON als Liste zur Datenhaltung:
XML vielleicht, aber die JSON-Impementation von Delphi ist grauenhaft und nicht dafür gemacht geändert zu werden.


Da es nur 3 Felder sind

Delphi-Quellcode:

TDictionary<{Key=.Key}Integer,TPair<{Parent=.Value.Key}Integer,{Name=Value.Value}string>>

Ansonsten ein TDictionary<> oder TList<> mit einem Record (wenn man die einzelnen Record-Werte oft ändern, oder nicht jedesmal den ganzen Record tauschen will, dann eben ein Data-Object und eine ObjectList)

Delphi-Quellcode:

TDataRec = record
  //Key:  Integer;
  Parent: Integer;
  Name:   string
  constructor Create(Key, Parent: Integer; Name: string);
end;

List.Add(TDataRec.Create(4711, -1, 'abc'));
List.Add(TDataRec.Create(0815, 4711, 'Bezeichnung fehlt'));
// oder
Dict.Add(4711, TDataRec.Create(-1, 'abc'));
Dict.Add(0815, TDataRec.Create(4711, 'Bezeichnung fehlt'));
// oder
...

[Kas Ob.]

Hi,
Well i think i do understand the question now.

Zitat:

Zitat von raller09 (Beitrag 1536012)

genau das ist meine Frage -> konkrete Idee für die interne Datenhaltung.

I designed and used a specific format for errors and notifications in at least 2 projects, so i will try to explain a similar approach for your use case, even if it doesn't fit your need, it might give you idea(s).

I would change your error report to something like this:

Code:

Customer 4711                                                           

    Item 0815

        Description missing.
        Sales price 2.45 below purchase price

    Article 666

        Container size is missing

$ERR1(entries)_13(named=Customer)_4711(identifier) _2(entries)_15(named=Item)_0815_2(entries)_1(named =Error)_4(errorcode=Description missing.)_1(named=Error)_5(errorcode=Sales price 2.45 below purchase price)_17(named=Article)_666(identifier)_1(named=e rror)_9(errorcode=Container size is missing)

and the short version (to be used version) will become

$ERR1_13_4711_2_15_0815_2_1_4_1_5_17_666_1_9

ERR 1 entry _ 13 = customer _ ......
....
in detailed view :

Code:

Customer 4711                                 customer =13

    Item 0815                                       item = 15

        Description missing.                        errorcode = 4
        Sales price 2.45 below purchase price       errorcode = 5

    Article 666                                     article = 17

        Container size is missing                   errorcode = 9

different types:
$ERR
$INF
$WRN
...
...

Points on the above :
1) You need an error (information/warning..) builder along with parser, this parser can be consumed by a redirector.
2) The Builder will build the short string above ($ERR..) for example, when generating an error the string will be built using the predefined values or the shipped values with the error messages (exception..) with extra codes, these values comes form an extra table or extra file, it doesn't matter, what does matter is these values will be fixed and predefined.
3) The Parser will build the text output message from the short string, using the same extra table or file mentioned above.
4) The Redirector will be able to translate actions like clicking on single line and perform an action, like clicking on the plain text output, like namely the line "Description missing." then redirector will can read it as the Item no= 666 and container, then perform the showing the according table and put the cursor on Container column.
5) The predefined values (table/file...) should never updated, i mean you can add but never delete or modify, just to be future versions compatible, these values will be read only once on stat the application/system and kept in memory for better performance.
6) That $ERR.. message can be saved in DB.
7) That $ERR.. can be sent by an email as text to different person running the application connected to the same system and he will get the full detailed text message and it will be clickable too.
8) If the message need extra fields then you can add extra field but in that case it is better if you switched to Base64 encoding for these parts, to explain on this : lets say this message "Sales price 2.45 below purchase price" need a parameter, the price then it could be included too as number, but for something else like Invalid Product name then you definitely need to encode it in that case just use Base64.
9) $ERR could encoded as Base64 in full too.
10) no problem in showing it ($ERR....) in the final output for the ease copy/paste/share...

Hope that was clear and helpful.