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

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