Direkt zum Hauptbereich

Nachtrag zum JSON Serialisierer ab Embarcadero Tokio 10.2

In einer meiner letzten Blogeinträge, sprach ich über meine Erfahrungen zu dem noch nicht so ganz vollständig dokumentierten JSON Serialisierer ab Tokio, hier nachzulesen unter Neuer JSOJN Serialisierer ab Tokyo

Bis jetzt hat er mir wertvolle Dienste erwiesen. Er ist ein Serialisierer wie man ihn sich wünscht bzw. kennt. Durch Unittests konnte ich diverse Möglichkeiten austesten. Zum Beispiel wollte ich nicht nur ein dynamisches TArray<T> als Liste exportieren, sondern auch eine TList<T>. Bei der TList<T> wurden aber immer alle Felder ins JSON geschrieben welche ich gar nicht brauchte. Natürlich gäbe es die Möglichkeit einer Ableitung und diese mit Attributen zu versehen aber wieso was neues erfinden. Eine andere aber meiner Meinung nach unschöne, ist das konvertieren einer TList<T> ToArray, ginge auch aber...

Wie man nur einen Teil der vordefinierten Typen serialisieren kann!

In diesem Fall kommt man um ein bisschen Code nicht herum, aber man kann mit TJsonDynamicContractResolver dynamisch Attribute hinzufügen oder entfernen. Wie macht man dies?

function TNathanUDV2Dto.ToJson: string;
var
  Serializer: TJsonSerializer;
  Resolver: TJsonDynamicContractResolver;
begin
  Serializer := TJsonSerializer.Create;
  try
    Resolver := TJsonDynamicContractResolver.Create;
    Resolver.ClearAttributes;
    Resolver.SetFieldsIgnored(TypeInfo(TList), ['FListHelper', 'FComparer']);
    Resolver.SetFieldName(TypeInfo(TList), 'FItems', 'Values');
    Serializer.ContractResolver := Resolver;
    Result := Serializer.Serialize(Self);
  finally
    Serializer.Free;
  end;
end;

Durch SetFieldsIgnored schliesse ich Felder aus, welche ich nicht im JSON haben möchte. Mit SetFieldName gebe ich ihnen einen anderen Namen.

Kommentare

Beliebte Posts aus diesem Blog

MVC mit System.Messaging

In der Vergangenheit hatte ich, beim Einsatz vom MVC Pattern immer eine eigene Implementation des Observer Pattern um Nachrichten vom Model ans View zu schicken. Hierbei handelte es sich um ein einfaches Record welches nur Text verschicken konnte. Das View musste deswegen auch immer das Model, bzw. das Interface des Model kennen um Daten für Aktualisierung zu haben. Dies widerspricht meiner Meinung nach, dem Prinzip von Clean Code "Separation of Concerns" und koppelt das View ans Model. Um dem entgegen zu wirken, experimentierte ich mit den Board-Mitteln Delphi, aus dem Namespace System.Messaging . Im View hänge ich mich an den DefaultManager der Klasse TMessageManager . procedure TFormShowMessage.FormCreate(Sender: TObject); begin FSubscriptionId := TMessageManager.DefaultManager.SubscribeToMessage(TMessage , procedure(const Sender: TObject; const AMessage: TMessage) begin Memo1.Lines.Add((AMessage as TMessage ).Value); end); end; Das Model schickt ...

Neuer JSON Serialisierer ab Embarcadero Tokio 10.2

Seit Embarcadero Tokyo 10.2 veröffentlicht hat, steht uns Entwicklern ein neuer sehr gut zu gebrauchender JSON Marshaller zur Verfügung. Leider ist die Dokumentation dürftig. Das schöne ist aber, das Embarcadero sich ziemlich an gängige Verfahren hält. So konnte ich z.B. sehr einfach herausfinden was TJsonCustomCreationConverter<T> macht, nachdem ich C# Beispiele analysierte. Da es leider keine offizielle Dokumentation zum TJsonSerializer gibt, beruhen meine Beispiele auf Versuch und Irrtum. Es gibt 3 Namespaces, welche relevant sind. Zum einen "System.JSON.Serializers", für den eigentlichen Serialisierer und die Klassenattribute, zum anderen "System.JSON.Converters", für eigene Konverter und zuletzt "System.JSON.Types", für z.B. Datumsformate oder Formatierungen. TJsonSerializer Ist die wichtigste Klasse, sie ist implementiert im Namespace System.JSON.Serializers. Diese Klasse ist dafür zuständig, ein Objekt in JSON (Serialisierung) zu formati...

Printer tests best practice...

Software ist heute einfacher zu entwickeln, nichts desto trotz steigt die Komplexität der heutzutage entwickelten Software. Dadurch steigt auch die Anzahl möglicher Fehler. Es ist jedoch nahezu unmöglich sämtliche Ausnahmefälle abzudecken. Deshalb ist kontinuierliches Testen der Software meiner Meinung nach, ein wichtiger und notwendiger Bestandteil jeder der Softwareentwicklung. Allzu oft wird heute noch, dies missachtet. Viel wird vermeintlich schnell behoben, was sich später bitterlich rächt. Einer dieser schnell schnell Punkt, ist das anpassen von Reports. In der Realität erlebe ich oft, das zu Reports meist gar keine automatischen Test existieren. Meist mit der Begründung, das geht nicht oder es existieren ja sowieso keine automatischen Tests. Vielleicht kommt noch, das testet dann der Kunde. Sucht man nach passenden antworten wie man Ergebnisse von Reports testen kann, kommt "Verwende Unittests". Das ist richtig, man sollte die gesamten vorlagerten Klassen mit...