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

[raller09]

Moin,

Zitat von TurboMagic:

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 von DeddyH:

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
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
...

[raller09]

Moin,

vielen Dank für eure Antworten. Ich brauchte tatsächlich einfach noch mal Ideen/Hinweise, wie ich das umsetzen soll...

Zitat von 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)

Denke, so werde ich das auch machen. Danke.


@Kas Ob.
Danke für die ausführliche Antwort. Ich werde das aber wohl mit den generischen Klassen umsetzen.

Zitat von mytbo:

Schaue dir mal den Quelltext des Beispiels aus diesem Artikel an. Vielleicht findest du dort eine Idee für die Umsetzung.

sehe ich mir an.


Danke

[Kas Ob.]

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

Zitat von raller09:

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.

[Kas Ob.]

One more thing:

I had a legacy project that needed something similar, and because it was huge and the modifications could take huge time, i worked around my way in it, converted the output view to TRichVeiw, colorful view one and shipped numbers along the text, similar numbers to my above post, these numbers where within after the plain text and marked (started with @$), these codes where colored with very faint grey color almost not visible so they will not interfere with the plain error message visibility (though they could be complete white and hidden), and by clicking on any line a script executed and consumed the numbers and codes to land or perform an action like open a specific table and put the cursor on specific row and column.

Again, hope that give you ideas.