JSON types et classes

**sekaijin** · 22/11/2010, 11h01

Bonjour à tous

Suite à quelques discussions sur des sujets voisins, voici quelques éléments sur le transport de données via JSON.

JSON est à la base une notation directement issue de javascript. Elle s'est émancipée de cette origine mais en garde tout de même des traces.

Les types transportés par JSON sont les types de base de javascript : String, Number, Boolean et les types structurés Array et Object.

JSON ne prévoit pas de typer plus fortement les données transmises.
Pas de date, char (date est une classe qui est dans le moteur JS mais pas dans le langage)

Encore moins de structure définie par l'utilisateur ni de classes (Javascript n'est pas un langage à base de classe mais un langage à prototype, donc on peut lui ajouter mais ce n'est pas dans sa nature)

Du coup il n'y a rien de précis sur le sujet.
Mais certains utilisent JSON pour inclure des informations de type.

La principale que j'ai trouvée consiste à inclure des noms de classe.
J'ai trouvé deux écoles : la première vient du monde java. Elle consiste à ajouter en "root élément" le nom de la classe

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"MyPojo":{"id":4, "name":"test"}}

C'est simple mais du coup la structure est changée. Là un un AJAX attendait

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"id":4, "name":"test"}

il reçoit un niveau hiérarchique de plus.
Côté PHP (Zend en autre) la solution proposée consiste à ajouter un membre de plus à l'objet

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"__ClassName":"MyPojo","id":4, "name":"test"}

Cela implique que l'objet ne peut avoir un membre __ClassName.
C'est la même approche qu'utilise objective j mais avec une clef différente

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"__objjClassName":"MyPojo","id":4, "name":"test"}

j'ai trouvé un exemple (non public désolé) qui code aussi les types mais ça devient lourd

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"o":"MyPojo":[{"s":"id", "i":45},{"s":"name", "s":"test"};]}

o pour object, i pour int s pour string etc
Dans ce cas il faut écrire un parseur spécifique pour récupérer son info car il ne contient pas le JSON "standard" dans ses parties.
Cette solution est très proche de php serialize

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

O:6:"MyPojo":2:{s:2:"id";i:45;s:4:"name";s:4:"test";}

Dans le même ordre d'idées mais en mixant les deux approches on peut envisager de transporter la description des types dans un membre et les données ensuite. Mais je n'ai rien trouvé de tel

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
{"__Types":{"O":{"ClassName":"MyPojo",{"i":"id","s":"name"}}},
"id":4, "name":"test"}

Tout cela ajoute de la lourdeur et de la complexité. Comment traiter une description dont les donnée ne correspondent pas, un int à la place d'un string par exemple etc.

Enfin pour finir une autre approche du problème est d'en passer par un schéma. Tout comme un XML se décrit par un xsd un JSON peut être décrit par un schéma lui même définit en JSON

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{"complexType":{
  "name":"MyPojo",
  "all":[
    {"element" {"name":"id",   "type":"integer"}}
    {"element" {"name":"name", "type":"string" }}
    {"element" {
      "name":"date",
      "type":"Date",
      "restriction":{
        "base":"string",
        "pattern":{"value":"[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}:[0-9]{3}"}
      }
    }}
  ]
}}

Ce schéma étant chargé une seule fois indépendamment des données pour permettre au parser de faire des vérification plus strictes
L'utilisation d'une notation comme

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

{"__ClassName":"MyPojo","id":4, "name":"test", "date":"2010-11-22 10:58:12:532"}

devenant suffisante pour typer plus fortement les données.

Bien sûr tout cela n'est pas normalisé et est un peu à l'opposé de la philosophie de base de JSON qui est par nature (très) faiblement typé

La solution "root élément" est facile à implémenter côté serveur et nécessite une adaptation côté client pour récupérer les donnes.

la solution "membre" est facile à mettre en œuvre côté serveur et est ignorée par Ajax, elle ne nécessite une adaptation côté client que si l'on veut exploiter les noms de classe.
Les deux ne typent pas les membres.

La solution que j'ai trouvée qui ressemble à php sérialize est plus complexe à mettre en œuvre côté serveur et me parait très complexe côté client. Elle nécessite d'écrire un PostParser qui après le parser JSON reconstruit l'objet final.

La solution mixte que j'ai extrapolée dans cet article est presque aussi lourde mais moyennant une petite adaptation on peut récupérer les données comme dans un JSON standard. Je ne voit pas l'utilité de faire cela.

Transporter le type dans les données est pour moi contre-productif, lourd et complexe.

Je pense que si l'on a un besoin de typage fort une description genre schéma (voire plus simple) me paraît plus appropriée car elle n'influence pas ou peu le trafic. Extjs utilise ce genre de description:

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{fields: [
 {name: 'company'},
 {name: 'price',      type: 'float'},
 {name: 'change',     type: 'float'},
 {name: 'pctChange',  type: 'float'},
 {name: 'lastChange', type: 'date', dateFormat: 'n/j h:ia'}
]}

A+JYT

**danielhagnoul** · 22/11/2010, 21h59

Bonsoir

C'est intéressant.

J'ai déjà vu et utilisé en "JavaScript - jQuery", un fichier JSON avec une structure hiérarchique vraiment complexe. Et pour s'y retrouver, l'auteur du fichier avait placé au début du fichier JSON une espèce de "Schema JSON".

Je trouve le principe très bon, mais difficile à généraliser, à moins que vous connaissiez une proposition de "norme" pour l'écriture de ce "Schema JSON" ?

**SpaceFrog** · 23/11/2010, 08h42

ça rejoint un peu le principe des datagrammes ...

**sekaijin** · 23/11/2010, 09h31

Non il n'existe rien de normalisé
seulement des efforts ici ou là par nécessite et bien sur incompatibles.

il y a un draft de l'IETF
http://tools.ietf.org/html/draft-zyp-json-schema-02
json-schema.org qui propose quelques description "standard", un métha-schéma pour la validation de type
http://json-schema.org/

on peut noter aussi le groupe google sur le json-schema-proposal-working-draft de ietf
http://groups.google.com/group/json-...-working-draft

ici une implémentation beta du valisateur associé

côté java http://jackson.codehaus.org/ inclus des outils

Il y a donc un effort de normalisation en cours
mais rien de définitif.
A+JYT

**nod__** · 24/11/2010, 09h08

et si on ajoutait des namespaces là dessus ? super on a refait XML.

Franchement j'ai du mal a voir l'intérêt de tout ça. Si il faut des schema et une structure de donnée à valider, XML et tous les outils adéquat existent déjà. Ça m'etonne pas de voir des gens de java là dedans, non sérieux ils se sont fait troller sur slashdot sur le xml qui est lourd et ils en veulent au JSON ?

JSON ça marche du feu de dieu par ce que c'est simple…

et si c'est pour transformer des données json en objets, la fonction JSON.parse() accepte une fonction en deuxième paramètre exactement pour cette raison.

Le fait d'envoyer uniquement des types simples c'est un soucis de sécurité, Niveau sécu c'est réglé, après il reste simplement à vérifier au moment ou on en a besoin que les données existent, faire la validation a priori c'est pas super utile vu tout ce que l'on peut faire sur les objets JS.

**sekaijin** · 25/11/2010, 09h55

Envoyé par nod__

et si on ajoutait des namespaces là dessus ? super on a refait XML.

Franchement j'ai du mal a voir l'intérêt de tout ça. Si il faut des schema et une structure de donnée à valider, XML et tous les outils adéquat existent déjà. Ça m'etonne pas de voir des gens de java là dedans, non sérieux ils se sont fait troller sur slashdot sur le xml qui est lourd et ils en veulent au JSON ?

Je suis entièrement d'accord pour dire que si on va trop loin dans ce sens on refait XML et que ça na pas d'intérêt majeur.

Envoyé par nod__

JSON ça marche du feu de dieu par ce que c'est simple…

et si c'est pour transformer des données json en objets, la fonction JSON.parse() accepte une fonction en deuxième paramètre exactement pour cette raison.[/QUOTE]
entèremetn d'accord JSON ça a été créé justement pour faire simple.

Envoyé par nod__

Le fait d'envoyer uniquement des types simples c'est un soucis de sécurité, Niveau sécu c'est réglé, après il reste simplement à vérifier au moment ou on en a besoin que les données existent, faire la validation a priori c'est pas super utile vu tout ce que l'on peut faire sur les objets JS.

On peut voir le process en plusieurs étapes.

Réception d'un flux JSON => on obtient une chaîne string (ou des erreurs de transport)
Parsing => on obtient un objet js (ou des erreur de parsing)
Consomation => on utilise les éléments de l'objet (et on peut avoir des erreurs du au fait qu'on ne trouve pas le nécessaire. et des erreur du à la consomation)

l'apport du typage (par schéma, description adhoc ou tout fonction js d'analyse locale) est de traiter les erreurs structurelle de contenu

Réception d'un flux JSON => on obtient une chaîne string (ou des erreurs de transport)
Parsing => on obtient un objet js (ou des erreur de parsing)
Validation=> on l'assurance que l'objet et bien celui attendu (ou des erreurs du au fait qu'on ne trouve pas le nécessaire)
Consomation => on utilise les éléments de l'objet (ou erreur du à la consomation)

la validation n'est donc pas à priori parce qu'on à défini un schéma elle peut se faire à la demande avant la consommation.
si on ne vérifie rien la méthode de consommation peut planter et il n'est pas simple de trouver pourquoi ni d'informer correctement l'utilisateur du problème (ou l'admin)
en général on se fait une petite vérif adhoc dans la méthode de conso. du coup s'il y a des pbs on peut les gérer et prévenir l'utilisateur.
avec un schéma on peut définir une méthode de vérification unique pour tous les échange JSON

en faire une norme permet de faire une méthode de validation qui est incluse dans l'objet JSON du navigateur donc compilé nativement.

mais le schéma n'apporte pas que la vérification. il permet aussi l'instanciation de classe. si je reçois un flux JSON de base contenant la définition d'un objet c'est un objet simple sans classe. si j'ai une description de schéma à lui associer je peux instancier la classe définie dans le schéma et obtenir un objet de cette classe contenant les données du flux json.
un exemple soit le JSON suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{"id": "nav","split": true,"width": 200,"minSize": 175,"maxSize": 400,"collapsible": true,"margins": "0 0 0 5","layout": {"type": "accordion","animate": true},"items": [{"contentEl": "west","title": "Navigation","border": false,"iconCls": "nav"}, {"title": "Settings","html": "<p>Some settings in here.</p>","border": false,"iconCls": "settings"}]}

si je le parse j'obtiens

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  id: 'nav',
  split: true,
  width: 200,
  minSize: 175,
  maxSize: 400,
  collapsible: true,
  margins: '0 0 0 5',
  layout: {
    type: 'accordion',
    animate: true
  },
  items: [{
    contentEl: 'west',
    title: 'Navigation',
    border: false,
    iconCls: 'nav'
  }, {
    title: 'Settings',
    html: '<p>Some settings in here.</p>',
    border: false,
    iconCls: 'settings'
  }]
}

si j'ai en plus associé à ce flux le schéma qui me dit que c'est objet est un Panel d'Extjs je n'ai plus un simple objet javascript mais un Panel
une instance de la classe Ext.Panel ce qui est fondamentalement différent.

là encore sans type on doit savoir exactement quoi faire du JSON savoir à l'avance que ce sera un Panel et l'instancier dans une fonction adhoc. si on veux pouvoir instacier un Panel un TabPanel un grid ou je ne sais quoi d'autre en fonction du paquet JSON qu'on reçois on est obligé de transmettre une information supplémentaire pour piloter se choix. il existe ne nombreuse façon d'y parvenir.
l'une d'elle est d'utiliser une description de type.
et si cette description de type est normalisée là encore cela permet de généraliser la méthode d'instanciation des objets.

un exemple simple suposons que mon JSON contienne comme le fait (php) le nom de la classe dans __ClassName. je peux écrire une méthode simple qui fait
si ClassName existe et est une classe alors instancier la classe avec les data du json
sinon générer une erreur. (ou autre option instancier un objet simple)

lorsque j'ai reçu mes données j'appelle ma méthode en question (la même pour tous les json reçus) et je peux appeler les méthodes de mon objet.

A+JYT

**nod__** · 25/11/2010, 23h35

Encore faut il que les classes existent… Ce qui n'est pas le cas en JS.

Dans l'histoire t'as deux couches d'abstractions qui ne sont pas dans le JS de base, donc tu aliènes tous les développeurs qui font du JS pur et dur pour faciliter ceux qui sortent de JAVA (en gros). Tu me diras – comme me l'as très justement fait remarquer mon chef de projet – « quitte à te faire enculer autant utiliser de la vaseline » (véridique) bah non, désolé.

Sur le parsage et les erreurs de transfert c'est un non problème, ton readyState il est à 4 ou pas, t'as les données ou pas. Si le parseur plante, c'est que le JSON est mal formé ce qui est une sacrée lose vu la simplicité du format.

« la validation n'est donc pas à priori parce qu'on à défini un schéma elle peut se faire à la demande avant la consommation » ça c'est la définition de a pirori ou je m'y connais pas. J'ai jamais dit qu'il ne fallait rien vérifier, j'ai dit qu'il fallait vérifier quand on en avait besoin. L'exemple de la boucle for sur un tableau "mes_objets" qui assigne un onclick avec un itérateur "i" sans closure où "i" se retrouve avec la valeur "mes_objets.length" pour tous les onclick me viens tout de suite à l'esprit.

JSON t'utilise ça pour des options, pour des données brutes, pas pour des abstractions. Tu rajoutes une pourriture de validation par dessus et ça deviens le successeur de l'applet JAVA, personne s'en sert.

Utiliser du JSON pour paramétrer un constructeur qui va te pondre un objet, je suis complètement d'accord, prendre un objet JSON en temps que représentation d'une classe (qui ne peux pas exister en dehors d'une lib) qu'il faut "sécuriser" pour garantir la bonne exécution c'est ridicule.

**danielhagnoul** · 26/11/2010, 00h18

Bonsoir

Le projet de norme JSON Schema (https://github.com/kriszyp/json-schema) n'en est qu'au stade "brouillon 3e version" mais il est très intéressant, il semble déjà bien connu sur la toile (sauf de moi

) et utilisé par plusieurs personnes et par différents langages de programmation.

Il y a d'autres avis (http://www.developpez.net/forums/d10...s/#post5611354 avec +2) mais pour ma part c'est ce qu'il manquait au "langage" pour être au niveau du XML.

Pour une utilisation simpliste du JSON, certains estimeront sans doute que cela ne se justifie pas (pourtant les exemples de petit fichier mal construit ne manquent pas), mais pour un travail en équipe, des fichiers construits par plusieurs auteurs, des fichiers distribués sur la toile il est indispensable de pouvoir garantir la solidité des fichiers.

Un autre avantage du JSON Schema c'est d'être facilement lisible par un humain et sans doute de pouvoir servir à d'autres tâches que la validation du fichier.

Il existe déjà plusieurs implémentations du projet de norme. Pour JavaScript je recommande JSV (JSON Schema Validator) qui se trouve ici : http://github.com/garycourt/JSV

Au moment où j'écris, il implémente la version 2 du projet de norme (http://tools.ietf.org/html/draft-zyp-json-schema-02), mais les mises à jour sont régulières.

Pour exemple, mon premier test - simpliste bien entendu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
<!doctype html>
<html lang="fr">
<head>
	<meta charset="utf-8">
	<meta name="Author" content="Daniel Hagnoul">
	<title>Forum jQuery</title>
	<style>
		/* Base */
		body { background-color:#dcdcdc; color:#000000; font-family:sans-serif; font-size:medium; font-style:normal;
		font-weight:normal; line-height:normal; letter-spacing:normal; }
		h1,h2,h3,h4,h5 { font-family:serif; }
		div,p,h1,h2,h3,h4,h5,h6,ul,ol,dl,form,table,img { margin:0px; padding:0px; }
		h1 { font-size:2em; text-shadow: 4px 4px 4px #bbbbbb; text-align:center; }
		p { padding:6px; }
		#conteneur { width:95%; min-width:800px; min-height:500px; margin:12px auto; background-color:#FFFFFF;
		color:#000000; border:1px solid #666666; }
 
		/* Test */
	</style>
</head>
<body>
	<h1>Forum jQuery</h1>
	<div id="conteneur">
 
	</div> 
	<script charset="utf-8" src="http://code.jquery.com/jquery-1.4.4.min.js"></script>
    <script charset="utf-8" src="../garycourt-JSV-bba0872/lib/uri/uri.js"></script>
    <script charset="utf-8" src="../garycourt-JSV-bba0872/lib/jsv.js"></script>
	<script charset="utf-8" src="../garycourt-JSV-bba0872/lib/environments.js"></script>
    <script charset="utf-8" src="../garycourt-JSV-bba0872/lib/json-schema-draft-01.js"></script>
    <script charset="utf-8" src="../garycourt-JSV-bba0872/lib/json-schema-draft-02.js"></script>
	<script>	
		$(function(){
 
var schema = { 
		"type" : "object",
		"items" : {
			"type" : "object", 
			"properties" : { 
				"id": {
					"type": "number"
				}, 
				"username": {
					"type" : "string"
				}, 
				"numPosts": {
					"type" : "number"
				}, 
				"realName": {
					"type" : "string",
					"optional": true
				}
			}
		}
	},
	json = { 
		"users": [ 
			{
				"id": 1,
				"username": "davidwalsh",
				"numPosts": 404,
				"realName": "David Walsh"
			}, 
			{
				"id": 2,
				"username": "russianprince",
				"numPosts": 12,
				"realName": "Andrei Arshavin"
			},
			{
				"id": 3,
				"username": "danielhagnoul",
				"numPosts": 380
			}
		]
	},
	JSV = require("./jsv").JSV,
	env = JSV.createEnvironment(),
	report = env.validate(json, schema);
 
console.log(report);
 
if (report.errors.length === 0) {
	console.log("YES !");
}
		});
 	</script>
</body>  
</html>

**nod__** · 26/11/2010, 01h07

Si c'est pour ça, écrit une doc. Un truc cool de java c'est javadoc, cf. la doc YUI.

« au niveau du xml » ouais ça et les namespaces (franchement les namespaces c'est bien : XMPP) mais jamais tu peux en faire en JSON, donc JSON ne pourra jamais être au niveau du xml. Ça tombe bien, ça n'a rien à voir.

Non mais sérieux, vous avez vu ce qui se passe en ce moment sur le JS ? les optimisations de oufs dans tous les sens sur les moteurs, les codes… et là on parle de rajouter une couche de traitement avant même d'utiliser les précieuses données tant convoités.

Et puis ça a déjà été dit ailleurs, la validation c'est coté serveur et javascript et un langage intrinsèquement non sécurisé. Dans le monde réel je ne vois aucune chance que ça devienne "mainstream", donc c'est de la branlette intellectuelle, super.

**sekaijin** · 27/11/2010, 11h43

Envoyé par nod__

Si c'est pour ça, écrit une doc. Un truc cool de java c'est javadoc, cf. la doc YUI.

« au niveau du xml » ouais ça et les namespaces (franchement les namespaces c'est bien : XMPP) mais jamais tu peux en faire en JSON, donc JSON ne pourra jamais être au niveau du xml. Ça tombe bien, ça n'a rien à voir.

Non mais sérieux, vous avez vu ce qui se passe en ce moment sur le JS ? les optimisations de oufs dans tous les sens sur les moteurs, les codes… et là on parle de rajouter une couche de traitement avant même d'utiliser les précieuses données tant convoités.

Et puis ça a déjà été dit ailleurs, la validation c'est coté serveur et javascript et un langage intrinsèquement non sécurisé. Dans le monde réel je ne vois aucune chance que ça devienne "mainstream", donc c'est de la branlette intellectuelle, super.

Je ne pense pas qu'il s'agisse d'ajouter une couche avant d'utiliser les données

il s'agit de se donner les outils permettant de se dispenser de refaire toujours les mêmes codes pour les mêmes problématiques.

cela n'empêche pas d'utiliser JSON comme on le fait aujourd'hui.

un exemple dans quelques lib on a la définition de DataStore qui sont des classe js qui permettent de stocker localement des données structurées. elles sont destinées à être utilisé par des composant comme les form les grid etc. elles possèdent donc le les méthodes nécessaires pour assurer cette interface.
dérivés de ces DataStores on a des ArrayStore des XmlStore des JsonStore qui sont capable de lirent leur données dans des array des flux XML ou JSON.

pour pouvoir "mapper les informations du Array, Xml, ou Json vers le DataStore on va au moment de la création de celui-ci définir la structure des données du datastore
la classe sera alors capable de lire sans qu'on ai une ligne de plus à écrire les données de la source (tableau, xml, json)

si on se penche sur le XmlStore on s'aperçois qu'on peut définir le DataStore en une ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ds = new XmStore({schemaUrl:'/schemas/personsLits.xsd'});

en JSON on ne peut pas. il faut soit écrire une procédure de lecture pour surcharger celle de la classe et y mettre la sémantique des champs du Json à lire soit décrire la structure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
ds = new JsonStore({
   total: 'count',
   root: 'persons',
   fields : [
      {name: ....}
   ]
});

avec cela plus besoin d'écrire une méthode de lecture celle de la classe générique peut charger le JsonStore automatiquement.

qu'apporte une norme ?
simplement que toutes les lib peuvent embarquer en standard une définition unique et ainsi décharger le développer de devoir définir une structure avec diverse méthodes en fonction de la la lib utiliser. et pouvoir simplement écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ds = new JsonStore({schemaUrl:'/schemas/personsLits.jss'});

mais rien de tout cela ne t'oblige à en passer par là. comme le dit danielhagnoul dans un travail d'équipe ça aide.

grosse différence entre un schéma et une javadoc c'est qu'avec un schéma on peut générer le code directement.
je travaille beaucoup sur les échanges inter système (pas inter application mais inter SI)
un schéma dans une définition d'un échange et chaque équipe dans son coin avec sa propre téchno peut générer dans son propre code l'ensemble des classes et outils nécessaires.

j'ai un esociété à lyon qui développe un outil sous windows C#.NET qui dans plusieurs SI va être émetteur et réceptionnaire de messages issue de SAP, d'un SI d'autres appli dans d'autres SI écrites en C++ et d'autres encore en java.

avec un schéma xml d'échange chaque industriel à généré dans son coin un parser pour lire les messages et des classes associé pour utiliser les données. dans tout ces environnement il on simplement pris le schéma et l'on passé à la moulinette.

JSON n'a absolument pas été retenu bien qu'en terme de volumétrie il était mieux placé. la raison l'obligation de devoir développer à la main ce qui fait automatique par XML.

même constat dans un appli PHP client web+JS XML à été retenu parce que le coût de dev était largement inférieur. cela venais du fait que en PHP et ej JS le prestataire à les outils pour générer automatiquement son code. pas de modèle métier à définir en JS ni en PHP
une seule définition en xsd et les deux partie sont disponibles.

UN Javadoc signifie qu'il faut u humain pour la lire et écrire à la main le code pour l'implémenter.
si on en fait un c'est jouable. lors qu'on fait ça des centaines de fois par ans ce n'est plus pareil.
si on le fait automatiquement on débuge UNE fois le générateur et on a la garantie que le code produit sera OK si on le fait à la main il y a un fort risque d'introdure des erreurs à chaque fois.

pour des échange unique définie une fois dans un coin il est plus SIMPLE de ne pas utiliser de schéma.
lorsqu'on passe à un stade industriel avec de nombreuse équipes sur des technologies disparates avoir une norme ça SIMPLIFIE les choses.

A+JYT

JSON types et classes

JavaScript

Discussions similaires

Partager

Partager