Objekte um Properties erweitern (Ein JavaScript-Rant)


#21

Das ist an sich natürlich praktisch - und/aber irgendwo muss JSON ja seinen Namen her haben. (Solche Krämpfe wie https://github.com/javagl/JsonModelGen kann man sich da sparen … und wenn es NUR darum ginge, könnte man auch versuchen, ein class Object extends LinkedHashMap<String, Object> in die JVM zu sneaken :smiley: ).

Aber gerade darauf bezieht sich meine Frage - siehe oben:

[QUOTE=Marco13;137075]
Ich lese ein Objekt aus JSON-Daten ein. Das Objekt hat (soweit die Sprache das eben erlaubt :rolleyes: ) einen konkreten Typ. Genaugenommen ist das ein sehr klarer, sehr spezifischer Typ: https://github.com/KhronosGroup/glTF/blob/master/specification/schema/buffer.schema.json Nun werden von der URI, die da drin steht, Daten gelesen - z.B. als ein ArrayBuffer. Soll ich jetzt einfach irgendwo reinschreiben
someBuffer.theArrayBuffer = readDataFrom(someBuffer.uri);
? Das wäre eigentlich praktisch und sinnvoll. Aber das Datenmodell enthält diese Property eigentlich nicht. [/QUOTE]


#22

Ja, das scheint praktisch zu sein, spricht eigentlich nichts dagegen. Wenn du aber auf Nummer sicher gehen will, kannst du auch Object.defineProperty verwenden.

Wobei du könntest für deine eigenen Variablen in fremden Objekten einen Prefix verwenden. Wäre sicher auch nicht schlecht um Kollisionen zu vermeiden.


#23

Ich habe noch etwas Interessantes gefunden, womit du sicherstellen könntest, dass die empfangene JSON sich an das vorgebene Schema hält: https://davidwalsh.name/json-validation


#24

[ot]
Hmja, Validation ist so eine Sache. Das JSON-Schema wurde ja zuletzt gezielt darauf ausgerichtet (bzw. die Validation gesondert betrachtet und spezifiziert). Aber da gibts noch ein bißchen Hickhack wegen JSONSchema-v3 und JSONSchema-v4 - welches wird denn jetzt verwendet? glTF verwendet das v3, daher würde das passen. Die haben auch gezielt https://github.com/KhronosGroup/glTF/issues/557 eröffnet (das sollte wohl über “syntaktische” validierung hinausgehen).

Ansonsten: Eine der Haupaufgaben des (Java-) Codes, der mit JsonModelGen erzeugt wird, IST ja gerade die ganzen Schema-Checks zu machen (wie auch in der GitHub-Readme als Beispiel angegeben). Für JavaScript … nun, da gehe ich einfach davon aus, dass das JSON richtig ist. Wenn nicht, kommt halt irgendwo auf der Konsole was mit “… is undefined” :rolleyes:
[/ot]


#25

Solange du die JSON-Datei von einer vertrauenswürdigen Quelle ladest, muss man sowieso davon ausgehen, dass die empfangene JSON-Datei valide ist.


#26

Nein, eigentlich muss Du ein externes JSON immer validieren. Eben weil Du nie sicher sein kannst, dass auch das ankommt, was Du erwartest. Nur so kannst Du robust mit anderen Schnittstellen arbeiten IMHO.


#27

Ich glaube, es ist letztlich die Frage, wie das Programm fehlschlagen soll: Entweder schlägt es bei der Validierung fehl oder mitten in der Programmlogik. “Externe” im Sinne einer API würde ich auf jeden Fall validieren. Doch auf einem CDN wäre es nicht so zwingend, da der JSON-Parser das Einschleusen von Schadcode verhindert.