Rückgabe-Typ anpassen?

[milos]

Hallo,

ich arbeite gerade an einem JSON-Parser.

Dies wäre eigentlich kein Problem, wenn ich nicht verschiedene Datentypen einbauen wollen würde

Hier ein kommentiertes Beispiel aus wiki:

Code:

{
  "id": 1, // integer
  "name": "Foo", // string
  "price": 123, // integer
  "tags": [ // array
    "Bar",  // array
    "Eek"   // array
  ],
  "stock": {
    "warehouse": 300, // string
    "retail": 20      // string
  }
}

Wie kann ich das am besten Lösen, dass ich alle Werte in der selben Klasse speichern kann, aber einen anderen Typen abspeichere?

Freundliche Grüsse

[Sir Rufo]

Ähm, du willst einen JSON-Parser erstellen oder benutzen?

Eigentlich gibt es schon genug JSON-Parser für Delphi ...

Im Übrigen sind die Kommentare nicht ganz korrekt:

Code:

{
  "id": 1, // integer
  "name": "Foo", // string
  "price": 123, // number
  "tags": [ // array
    "Bar", // array-item string
    "Eek"  // array-item string
  ],
  "stock": { // object
    "warehouse": 300, // number
    "retail": 20      // number
  }
}

Zwingende Basis-Lektüre ist hier auch http://json.org

[Popov]

Zitat von Sir Rufo:

Ähm, du willst einen JSON-Parser erstellen oder benutzen?

Eigentlich gibt es schon genug JSON-Parser für Delphi ...

Mal etwas OT. Ist die Aussage richtig? Als ich das letzte Mal auf die Idee kam mal JSON auszuprobieren, hat nichts, aber auch wirklich nichts mit Delphi 7 problemlos funktioniert. Irgendwann gab ich es auf. Gibt es inzwischen so große Auswahl, dass ich es erneut versuchen kann und der TE drauf verzichten kann etwas neues zu schreiben?

[Bernhard Geyer]

Zitat von Popov:

Mal etwas OT. Ist die Aussage richtig? Als ich das letzte Mal auf die Idee kam mal JSON auszuprobieren, hat nichts, aber auch wirklich nichts mit Delphi 7 problemlos funktioniert. Irgendwann gab ich es auf. Gibt es inzwischen so große Auswahl, dass ich es erneut versuchen kann und der TE drauf verzichten kann etwas neues zu schreiben?

Es gibt schon eine größere Auswahl (Google nach: "JSON parser Delphi"). Ob diese halt auch noch bei einer 13 Jahre alten IDE funktionieren ist offen. Eine JSON-Komponenten zu schreiben wird einfacher sein wenn man mit der erweiterten RTTI schon einiges an Arbeit abnehmen lassen kann.

[himitsu]

Ob es mit Delphi 7 laufen wird ... mal sehn (die paar RTTI-Funktionen sollten sich abschalten lassen, auch wenn dann die De-Serialisierungsfunktionen fehlen würden)
Die Grundfunktionen meines Codes kommen ohne RTTI aus. (aber fertig ist er noch nicht, siehe Link in 3)
http://www.delphipraxis.net/184540-i...d-nextgen.html

Und der Code des TE wird garaniert auch mit D7 laufen, wenn fertig, denn von RTTI Und Co. ist da drin noch nix zu sehen.

Aber ja, es gibt bestimmt auch schon was Fertiges, was in Delphi 7 laufen würde.
Wie alt ist JSON eigentlich? Würde auf 2005 oder 2006 tippen und Delphi 7 ist aus dem Jahre 2002, aber wenn ein Code in Delphi 2006/2007 läuft, dann bestimmt auch in D7.

[milos]

Erstmal danke, dass ihr euch Zeit genommen habt um zu antworten.

Zitat von himitsu:

Dein Zurückgeben geht und man kann es auch so machen,
wobei es natrülich etwas doppelt gemoppelt ist, da der Compiler anhand der Signatur (die Typen der Parameter, aber nicht des Results) auch automatisch unterscheiden kann. (overload)

Hab den Code ein wenig verbessert:
http://pastebin.com/E4j8K961
PasteBin um zu viel Code auf der Seite zu vermeiden.
Den Tipp mit GetValue habe ich umgesetzt.

Zitat von himitsu:

Zitat von milos:

Leider habe ich keine Ahnung wie ich damit nochmal ein ganzes Objekt oder Variable zurückgeben kann.

Was ist Variable?

War müde, meinte eigentlich Arrays
Aber wenn das so klappt wie ich es mir denke sollte es kein Problem sein.

Was ich nicht ganz verstehe ist, wie ich wieder ein ganzes Objekt zurück geben kann, denn TJsonValue kann TJsonNodes ja gar nicht kennen, wie kann ich dann ein GetValue für TJsonNodes machen der mir dann wieder ein ganzes Objekt zurück gibt?
Habe leider nicht ganz verstanden was du mit TMyObject usw gemeint hast.

Zitat von Popov:

Mal etwas OT. Ist die Aussage richtig? Als ich das letzte Mal auf die Idee kam mal JSON auszuprobieren, hat nichts, aber auch wirklich nichts mit Delphi 7 problemlos funktioniert. Irgendwann gab ich es auf. Gibt es inzwischen so große Auswahl, dass ich es erneut versuchen kann und der TE drauf verzichten kann etwas neues zu schreiben?

Ich schreibe diese Unit um einen (vorallem kleinen) simplen aber auch gut funktionierenden Json-Parser zu haben mit dem ich Schreiben und Lesen kann. Das es draussen im grossen, weiten Internet schon funktionierende und fertige Sachen gibt, bin ich mir durchaus bewusst, werde diese jedoch nicht benutzen. Wie himitsu schon erwähnt hat, sollte der Parser ohne Probleme in Delphi 7 funktionieren, da ich versuche auf Abhängikeiten die nicht gerade jeder so hat zu verzichten.

Freundliche Grüsse

[himitsu]

Zitat:

Code:

  "stock": { // object
    "warehouse": 300, // integer
    "retail": 20      // integer
  }

[add]

Zitat von Sir Rufo:

Zwingende Basis-Lektüre ist hier auch http://json.org

Ich glaub diese Lektüre haben zu viele JSON-Parser-Entwickler (außerhalb der Welt von JavaScript und kompatiblen dynamischen Sprachen) zu wörtlich genommen.
True und False als einzelne Objekte
[/add]

Zitat:

Ähm, du willst einen JSON-Parser erstellen oder benutzen?

Gute Frage ... wenn wirklch "erstellen", dann:



Variant und TValue können mehrere "Typen" speichern

oder du reagierst auf den Typen und speicherst dann den "Wert" in einer entsprechenden Variable, ähnlich einem varianten Array.
> String, Double, Array/Objekt, ...

Aber warum schaust du nicht einfach bei anderen Delphi-JSON-Libs ab?
z.B. http://sourceforge.net/projects/lkjson/

(ich weiß jetzt nicht, welche Lib Delphi integriert hat)






Warum baut eigentlich jeder einen JSON-Parser?



*hust*
http://svn.geheimniswelten.de:8080/svn/JSON/ (nicht fertig)
Ich hab mich entschieden die "Werte" als String zu speichern. (im Prinzip ist es im JSON dann eh alles ein String)


Wobei ich keinen JSON-Parser bastel (OK, der TJSONReader ist eine Art SAXParser), sondern ein echtes DOM, welches vollständig bearbeitbar ist.
Das Projekt war aber eigentlich entstanden, um die Speicherverwaltung im Multiplattform an einem praktischen Beispiel zu testen.
Siehe die vielen Tickets ala http://www.delphipraxis.net/184063-m...interface.html

Es gibt dazu dbald auch mal einen Artikel über JSON, JavaScript, Delphi, wie das drüben ist, also im JavaScript und vielleicht auch anderswo, und warum das JavaScript-Objekt-Model-Prinzip (nur serialisieren und deserialisieren) nicht unbedingt mit Delphi kompatibel ist.

[Sir Rufo]

Warum sollte da was mit Delphi nicht kompatibel sein?

Wenn dem so ist, dann ist Delphi auch nicht mit XML bis hin zu einem Binär-Daten-Format kompatibel (ja, serialisieren).

[himitsu]

Weil Delphi keine dynamischen Typen erlaubt?
'ne Variable, wo wirklich alles rein passt und das beliebig verschachtelbar ... das kennt Pascal nativ erstmal nicht.

Ein Variant kann zwar einfache Typen und Arrays enthalten und Objekte, aber nativ keine benamten Objekte, außer man klemmt z.B. ein Dictionary dazwschen.

In JavaScript kann man JSON einfach so deserialisieren und JS baut dann dynmaisch ein Objekt auf, Anhand der gefundenen "Property"-Namen.
Dort ist es eben möglich zur Laufzeit das Objekt umzubauen, was in einer statischen Sprache, wie z.B. Delphi, einfach nicht möglich ist, außer man baut sich dort entsprechende Wrapper-Klassen, so wie sie in fast jedem JSON-Parser enthalten sind.

Entweder man muß der JSON-Deserialisierung geziehlt ein Objkekt/Klasse geben, was schon vorher die nötige Struktur besitzt, oder man baut eben Datenhaltungsklassen in den Baum (ala TJsonObject oder TJsonValuse, wie sie meistens heißen).

[Sir Rufo]

Ja, das gleiche Problem hat man mit XML, CSV, Ini-Dateien, ... Binär-Daten.

Aber Java scheint ja eine Zaubersprache zu sein. Da kann man einfach so irgendein JSON rüberschicken und schwupps kann die Anwendung sofort das korrekt interpretieren?

Oder muss selbst bei Java der Kontext klar sein? Was bringt mir die dynamische Instanz, wenn die Anwendung die Eigenschaft "wuppdi" nicht kennt und somit nicht verarbeiten kann? Ich würde mal sagen: Nichts.

Denn die statische Klasse ohne wuppdi Eigenschaft ist genauso gut/schlecht wie die dynamische Klasse mit der Eigenschaft, die aber von der Anwendung nicht berücksichtigt wird.