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