TJSONObjectBuilder keine leeren Objekte/Arrays

[Zacherl]

Hallo zusammen,

ich schaue mir grade das System.JSON.Builders Framework an. Rufe ich dort:

Delphi-Quellcode:

Builder
  .BeginObject
    .BeginObject('test')
    .EndObject
  .EndObject

auf, dann erhalte ich als Output:

Code:

{
  "test": {}
}

also ein leeres Objekt namens "test".

Macht soweit natürlich Sinn. Meine Frage jetzt aber trotzdem:
Ist es möglich die Objekte/Arrays erst dann zu schreiben, wenn sie mindestens ein eigenes Feld besitzen?

Hintergrund ist, dass ich eine Hierachie von Klassen serialisieren will. Jede Klasse besitzt eine Serialize Methode, der ich eine Builder Instanz und den Feldnamen übergeben will. Die Instanz soll sich dann selbstständig serialisieren. Jetzt kann es passieren, dass alle Felder der Instanz die Standardwerte besitzen. In diesem Falle sollen die Felder nicht im JSON erscheinen.
Ich würde nun gerne weiterhin die Felder nach und nach prüfen, also:

Delphi-Quellcode:

Builder.BeginObject(FieldName);
if (Field1 <> Default1) then Builder.Add('field1', Field1);
if (Field2 <> Default2) then Builder.Add('field2', Field2);
..
Builder.EndObject;

Ist sowas mit dem System.JSON.Builders Framework möglich, oder müsste ich tatsächlich vor dem BeginObject erstmal alle Felder auf Standardwerte prüfen?

Viele Grüße
Zacherl

[himitsu]

BeginObject erstellt ein neues Objekt
und Objekte ohne Eigenschaften sind natürlich möglich.

Also vorher prüfen oder nachher das Objekt wieder löschen.

[Zacherl]

Zitat von himitsu:

Also vorher prüfen oder nachher das Objekt wieder löschen.

Vorher alle Felder prüfen ist ja genau das, was ich nicht will. Dann habe ich alle Checks doppelt:

Delphi-Quellcode:

if (Field1 <> Default1) and (Field2 <> Default2) and ... then
begin
  Builder.BeginObject(FieldName); 
  if (Field1 <> Default1) then Builder.Add('field1', Field1);
  if (Field2 <> Default2) then Builder.Add('field2', Field2);
  ..
  Builder.EndObject;
end;

Objekt nachher löschen: Sicherlich. Im Builder selbst habe ich dafür allerdings keine entsprechenden Methoden gefunden. Einziges Workaround, was mir im Moment vorschwebt, ist es vor dem Builder.BeginObject(FieldName) die Position von TStreamWriter(Builder.Writer).BaseStream zu sichern und nach dem Builder.EndObject zu schauen, ob die Position mehr als 2 Bytes erhöht wurde. Dann könnte ich das leere Objekt über Stream.Position -= 2 wieder löschen. Schön ist aber anders.

[himitsu]

if (Field <> Default) then Builder.Add('field', Field);
in eine Methode auslagern, da prüfen und wenn True, vorher schauen, ob das Objekt angelegt wurde und wenn nicht, dann das BeginObject und danach das Add
Am Ende auch nur das EndObject, wenn das Objekt existiert.

[Der schöne Günther]

Eine Frage die garantiert nicht weiterhilft: Ist das denn schlimm wenn da ein "leeres Objekt" ist? Als Mensch hätte ich direkt gesehen "Ja, 'test' ist belegt und darin ist nichts besonderes mehr das vom Standard abweicht".

[Zacherl]

Zitat von himitsu:

if (Field <> Default) then Builder.Add('field', Field);
in eine Methode auslagern, da prüfen und wenn True, vorher schauen, ob das Objekt angelegt wurde und wenn nicht, dann das BeginObject und danach das Add
Am Ende auch nur das EndObject, wenn das Objekt existiert.

Ja, so ähnlich hatte ich die Funktionalität in meinem eigenen "Builder Framework" implementiert (als es das noch nicht in der RTL gab). Vermutlich die bessere Alternative zu dem Stream Gewusel

Zitat von Der schöne Günther:

Eine Frage die garantiert nicht weiterhilft: Ist das denn schlimm wenn da ein "leeres Objekt" ist? Als Mensch hätte ich direkt gesehen "Ja, 'test' ist belegt und darin ist nichts besonderes mehr das vom Standard abweicht".

Schlimm nicht, bloß möchte ich das Format bewusst möglichst gut lesbar gestalten. Konkret handelt es sich um diese Datei:
https://github.com/zyantific/zydis-d...tructions.json

Jede einzelne Instruction kann z.b. bis zu 10 Operanden besitzen. Wenn ich da jetzt für jeden möglichen Eintrag ein leeres Objekt anlege, kann das doch ziemlich schnell unübersichtlich werden.

[Fritzew]

Wir hatten ein ähnliches Problem, allerdings mehr "allgemein" zum feststellen ob ein Object modifiziert wurde.
Die Lösung bei uns war konsequent für alle properties Setter zu verwenden.

aka :

Delphi-Quellcode:

procedure setProperty1(const Value : integer);
begin
 if Value <> fProperty1 then
 begin
  fproperty1 := Value;
   // Call do set the modifiedFlag
   domodified;  
 end;
end;

So können wir im Source einfach testen:

if Obj.modified then ....... Hat sich bewährt kommt aber wohl auf den Anwendungsfall an...

[Zacherl]

Zitat von Fritzew:

Wir hatten ein ähnliches Problem, allerdings mehr "allgemein" zum feststellen ob ein Object modifiziert wurde.
Die Lösung bei uns war konsequent für alle properties Setter zu verwenden.

Setter für alle Properties und ein Changed Event besitzen meine Klassen sogar schon. Ist leider für meinen speziellen Fall nicht die beste Lösung, da durch eine Modifikation der Wert einer Property ja auch wieder auf den Standardwert gesetzt werden könnte. Das hieße, dass ich den Check lediglich in die Setter auslagern würde und dann noch einen internen Counter bräuchte, der bei Property <> Default inkrementiert und bei Property = Default wieder dekrementiert wird (Counter = 0 <=> Objekt hat nur Default Properties ).

Zitat von himitsu:

if (Field <> Default) then Builder.Add('field', Field);
in eine Methode auslagern, da prüfen und wenn True, vorher schauen, ob das Objekt angelegt wurde und wenn nicht, dann das BeginObject und danach das Add
Am Ende auch nur das EndObject, wenn das Objekt existiert.

Werde jetzt mal schauen, ob sich das generisch - und trotzdem performant - umsetzen lässt, ohne für jeden Datentyp eine extra Funktion erstellen zu müssen.