JSON richtig parsen

[Der schöne Günther]

Du machst es dir viel zu kompliziert - Das ist alles schon fertig: Mit TJson.JsonToObject<TErrorMessage>(yourJsonObject) hast du eine automatische Umwandlung deines Json-Objekts in TErrorMessage.

Hier als Beispiel:

Delphi-Quellcode:

// JCL_DEBUG_EXPERT_GENERATEJDBG OFF
// JCL_DEBUG_EXPERT_INSERTJDBG OFF
// JCL_DEBUG_EXPERT_DELETEMAPFILE OFF
program Project19;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.IoUtils,
  System.Json,
  Rest.Json,
  Unit10 in 'Unit10.pas';


const
   filePath = 'y:\jsonTest.txt';

procedure parseJson();
var
   fileContent:       String;
   messagesJson:      TJSONArray;
   messageJson:      TJSONValue;

   messageObject:      TErrorMessage;
   messagesObjects:   TArray<TErrorMessage>;
begin
   fileContent := TFile.ReadAllText(filePath);

   messagesJson := TJSONObject.ParseJSONValue(fileContent) as TJSONArray;

   messagesObjects := [];
   for messageJson in messagesJson do begin
      messageObject := TJson.JsonToObject<TErrorMessage>(messageJson as TJsonObject);
      messagesObjects := messagesObjects + [messageObject];
   end;

   readln;
end;

begin
   parseJson();
end.

PS: Ja, die Umwandlung stammt aus Rest.Json.pas die beim RAD-Studio dabei ist. Ich wundere mich auch, was das mit REST zu tun haben soll, warum das nicht auch in System.Json.pas steckt. Aber das ist hoffentlich kein Stolperstrick?

[Hobbycoder]

Danke Das funktioniert ja wie geschnitten Brot

Zu meinem Verständnis: Die Voraussetzungen sind, nehme ich mal an, dass a) der JSON-String NUR ein Array enthält, und b) die Bezeichner für die Values innerhalb des Array den Properties des Objekts entsprechen?
Wie findet die Funktion denn die passenden Properties? Und werden die Typen immer passend umgewandelt (String, Int, TDatetime, etc)?

[Der schöne Günther]

Zu a)

Ja - Eigentlich musst du ja im Voraus wissen, was du bekommst. Ob es ein Array mit X Dingen drin ist, oder nur ein Ding. Wenn beides auftreten kann muss dein Code mit beiden Wegen zurechtkommen. Oder meinst du dass der "richtige" Inhalt wiederum ein Objekt mit einer Handvoll Feldern und ein Feld ist dieses Array? Auch das ist kein Problem, man muss es nur abbilden im Code.


Zu b)
Das Umwandeln des Json in dein TErrorMessage-Objekt fasst die Properties nicht an. Das siehst du wenn du z.B. einen Haltepunkt in deine Setter-Methode setzt. Der "Marshaller" erstellt zuerst ein TErrorMessage-Objekt, dann sucht er sich für jedes JSON-Feld das passende Feld in deinem Delphi-Objekt und steckt den Wert da hinein. Da der JSON-String den du angegeben hast anscheinend einwandfrei war, klappt das auch mit Dingen wie TDateTime (wie man sieht).

Eine Besonderheit: In deinem Fall hat das so toll geklappt weil du dieser merkwürdigen Konvention (bzw. oft leider Notwendigkeit) folgst allen Feldnamen immer ein "F" voran zu stellen. In deinem Json-String ist das nicht so. Trotzdem hat das geklappt. Warum das so ist steht hier:
http://www.delphipraxis.net/182105-f...unmarshal.html

Ich rege mich darüber eher auf, aber im verlinkten Thema steht auch wie du z.B. die Felder in deiner Klasse auch anders nennen kannst als im JSON und der Mechanismus trotzdem weiterhin funktionieren kann.

[Hobbycoder]

Den verlinkten Artikel habe ich gelesen.

Demnach scheint, auch wenn du keine Freund davon bist, eine einheitliche Namenskonvention zwischen json und objekt für die geringsten Komplikationen zu sorgen. Damit kann ich leben.
Mein Objekt umfasst ja mehr Properties, als im Json übermittelt. Du Funktion hat damit keine Probleme.
Was aber passiert im umgekehrten Fall? Kommt eine Exception, oder ignoriert die Funktion das dann einfach? Das könnte ja schnell passieren, denn nicht immer hat man selbst Einfluss auf den JSON-String bzw. wann der mal verändert wird.
(Ich könnt's auch ausprobieren, aber vielleicht weißt du das auch so.)

[Hobbycoder]

Und ein Problem hab ich dann doch noch.
Ich habe ja 2 Properties als enumeration type.

Delphi-Quellcode:

  TEMStatus=(emsNeu, emsIB, emsKorr, emsGepr);
  TEMDringlichkeit=(emdLowest, emdLower, emdNormal, emdHigh, emdHighest);

  property Status: TEMStatus read FStatus write SetStatus;
  property Dringlichkeit: TEMDringlichkeit read FDringlichkeit write SetDringlichkeit;

Das würde ich auch gerne so belassen.

Diese werden von TJson.JsonToObject<TErrorMessage>(messageJson as TJsonObject) nicht korrect gesetzt. Wahrscheinlich eher gar nicht, da json selbst diese Datentypen nicht kennt.
Da ich sie auch nicht im Create vordefiniere, bleiben sie ohne wert und können bei der späteren Verwendung auch nicht korrekt gecastet werden.

Wie löst man sowas? Im JSON sind die ja als Integer drin.

[Der schöne Günther]

Zu 1)
Ich habe es nicht im Kopf, aber durch Ausprobieren sieht man meine ich dass er weder auf die Nase fällt wenn dein Objekt mehr Felder hat als das Json, noch umgekehrt wenn das Json mehr Felder hat als dein Objekt. Eigentlich ist dir ja klar was du als Json bekommst. Das ist doch ein perfekter Kandidat für Unit-Tests. Sollte sich der Json-Mechanismus in Delphi eines Tages ändern würdest du das mit deinen Tests ja sofort merken wenn dort etwas nicht mehr stimmt

Zu 2)
Enumemerationen sind jetzt etwas kniffelig. Denn in JSON gibt es so etwas nicht. Deine Gegenstelle legt die jetzt als Integer ab sagst du. Hätte man auch als Strings machen können. Ich sehe zwei Möglichkeiten:

1. Einen eigenen JSON-Interceptor bauen
2. Die billige Lösung

Der Interceptor würde die Zahl aus deinem Json auswerten können und wieder auf deinen Enum-Typen zurückführen können. Ich finde hier im Forum einmal etwas dazu, bekomme es selbst aber auf die Schnelle nicht mehr hin.

Ich finde es auch in dem Fall einen Overkill. Im Fall Enum/Zahl - ganz ehrlich - Warum nicht einfach die Felder in deinem Objekt auch als Zahl (z.B. Byte) machen und die Getter & Property anpassen? Zu irgend etwas müssen diese Getter ja gut sein

Delphi-Quellcode:

type
   TEMStatus=(emsNeu, emsIB, emsKorr, emsGepr);

   TEMDringlichkeit=(emdLowest, emdLower, emdNormal, emdHigh, emdHighest);

   TErrorMessage = class
      private var
         FStatus:      Byte;
         FDringlichkeit:   Byte;
      private
         function getStatus(): TEMStatus;
         function getDringlicheit: TEMDringlichkeit;
      public
         property Status: TEMStatus read getStatus;
         property Dringlichkeit: TEMDringlichkeit read getDringlicheit;
   end;


implementation

{ TErrorMessage }

function TErrorMessage.getDringlicheit(): TEMDringlichkeit;
begin
   Result := TEMDringlichkeit(FDringlichkeit);
end;

function TErrorMessage.getStatus(): TEMStatus;
begin
   Result := TEMStatus(FStatus);
end;

[Jumpy]

Warum kann man eigentlich Properties nicht überladen? Das wäre doch jetzt echt praktisch für diesen Fall.