IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le format XML serait meilleur que JSON pour la mise en page d'interface utilisateur
Selon Adam Stepinski, directeur de l'ingénierie chez Instawork

Le , par Bill Fassinou

482PARTAGES

15  0 
Les formats JSON et XML sont deux des formats de fichiers les plus utilisés dans la programmation. L’un est orienté données (JSON) et l’autre est orienté documents (XML) et ils peuvent tous les deux être utilisés pour recevoir des informations (données) d’un serveur. Selon Adam Stepinski, directeur de l’ingénierie chez Instawork, JSON peut se montrer plus utile et un meilleur choix que XML dans plusieurs domaines, mais s’il y a un domaine dans lequel XML est de loin le meilleur choix, c’est la mise en page des interfaces utilisateurs.

JSON signifie JavaScript Object Notation. C'est un format de fichier standard ouvert utilisé pour les communications navigateur-serveur. C'est un format de données indépendant du langage. XML signifie Extensible Markup Language. XML représente un ensemble de règles qui aident les utilisateurs à coder des documents dans un format lisible par l'homme et par la machine. Pour cette dernière raison, Adam Stepinski, directeur de l’ingénierie chez Instawork et son équipe pensent que le format XML est le meilleur choix dans la conception des interfaces utilisateurs.


Stepinski et son équipe ont développé Hyperview XML (HXML), un nouveau format hypermédia basé sur XML et un client React Native pour le développement d'applications mobiles pilotées par serveur. Hyperview XML est un format hypermédia utilisé pour définir les écrans (interfaces utilisateurs) d'applications mobiles. HXML fournit un ensemble de balises et d'attributs qui permettent de définir la disposition d'un écran, le style et les interactions utilisateurs disponibles. Les comportements en HXML définissent les actions qui doivent se produire dans l'application.

Ces actions sont une réponse à un déclencheur basé sur l'utilisateur. Les comportements peuvent être spécifiés soit comme attributs sur d'autres éléments HXML, soit comme un élément enfant <behavior>. Selon l’équipe de développement de l’outil, sur le Web, les pages sont rendues dans un navigateur en récupérant le contenu HTML à partir d'un serveur. Avec HXML, les écrans sont rendus dans votre application mobile en récupérant du contenu Hyperview XML depuis un serveur. La conception de HXML reflète l'interface utilisateur et les modèles d'interaction des interfaces mobiles d'aujourd'hui.

Selon Stepinski, chaque format permet de faire des compromis en matière de codage, de flexibilité et d'expressivité pour répondre au mieux à un cas d'utilisation spécifique. Autrement dit, un format optimisé pour la taille utilisera un encodage binaire qui ne sera pas lisible par l'homme, un format optimisé pour l'extensibilité prendra plus de temps à décoder qu'un format conçu pour un usage restreint et enfin un format conçu pour des données plates (comme CSV pour Comma-separated values) aura du mal à représenter des données imbriquées.

Outre les propriétés intrinsèques d'un format, Stepinski explique aussi que des facteurs externes peuvent influencer ses cas d'utilisation pratique, tels que la popularité du format auprès des développeurs cibles ou le support des bibliothèques dans les langages de programmation souhaités. « Lorsqu'ils choisissent un format de fichier à utiliser dans un projet logiciel, les ingénieurs en logiciel choisissent celui qui présente le meilleur équilibre entre les caractéristiques et les facteurs externes pour la situation », a-t-il déclaré dans un billet explicatif.


Pour Stepinski, JSON représente un meilleur choix que XML dans l’utilisation des listes. Le format XML est plus utile pour exploiter les arbres

D’après Stepinski, par exemple, JSON représente un meilleur choix que XML dans l’utilisation des listes. Par contre, le format XML sera plus utile pour exploiter les arbres. Il estime que JSON est bien plus adapté que XML pour représenter des listes d'objets aux propriétés complexes. La syntaxe clé/valeur de l'objet JSON facilite les choses. En revanche, la syntaxe des attributs XML ne fonctionne que pour des types de données simples. L'utilisation d'éléments enfants pour représenter des propriétés complexes peut entraîner des incohérences ou une verbosité inutile.

Pour lui, JSON excelle dans la représentation d'une collection d'objets homogènes, où les propriétés des objets peuvent être des types de données composites. D’un autre côté, XML excelle dans la représentation d'arbres avec des objets hétérogènes, où les propriétés des objets sont des types de données simples. Dans ce cas de figure, lorsque l’on voit les interfaces utilisateurs comme des arbres, Stepinski dit que XML est le format de représentation le mieux adapté. Selon Stepinski, les dispositions de l'interface utilisateur sont des arbres.


Adam Stepinski

C’est la raison pour laquelle ils ont conçu Hyperview en se basant sur le format XML existant. Stepinski a expliqué que les arborescences de composants sont le meilleur moyen de représenter les mises en page de l'interface utilisateur et que tous les principaux frameworks d'interface utilisateur utilisent une arborescence de composants. D’après lui, Xcode fournit même une vue 3D éclatée qui met réellement en évidence l'arborescence sous-jacente d'une interface : chaque composant a un composant parent, et tout se transforme en un composant racine partagé.

« Les structures de l'interface utilisateur sont représentées sous forme d'arbres de composants. Et XML est idéal pour représenter des structures arborescentes. C'est un mariage fait au paradis ! En fait, les frameworks d'interface utilisateur les plus populaires dans le monde (HTML et Android) utilisent la syntaxe XML pour définir les modèles », a déclaré Stepinski. Il donne l’exemple de React, le framework de composants graphiques de Facebook, qui recommande aussi de définir l'interface utilisateur des composants à l'aide de JSX, un format semblable à XML.

D’après lui, même si l'utilisation de JSX nécessite l'apprentissage d'une nouvelle syntaxe non-JS et l'ajout d'une étape de transplantation au processus de compilation, les concepteurs de la bibliothèque estiment que cela vaut la peine d'utiliser XML. « Les arbres sont une représentation puissante pour les agencements d'interface utilisateur. Ils fournissent naturellement des regroupements de composants, permettant aux concepteurs et aux développeurs d'utiliser des abstractions de plus haut niveau », a-t-il expliqué, dans son billet.

« Lorsque nous avons besoin de cacher, afficher ou animer une section de l'écran, nous n'avons pas besoin de changer l'état de chaque composant de la section. Nous pouvons plutôt changer l'état du composant parent unique qui contient chaque élément de l'interface utilisateur de la section. Lors de la modification d'un composant, nous n'avons qu'à nous préoccuper de ce qui se trouve dans son sous-arbre, et non de ce qui se passe à des niveaux supérieurs », a-t-il conclu.

Source : Adam Stepinski

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des arguments de Stepinski ? Êtes-vous du même avis ou pas ? Pourquoi ?
Quel type de format préférez-vous et pourquoi ?

Voir aussi

JavaScript : faut-il privilégier les transformations XML à JSON et aux Frameworks ? Partagez vos avis

React : la version 16.8 de la bibliothèque JavaScript est disponible et embarque une version stable des Hooks

Une interface utilisateur évidente est souvent la meilleure interface utilisateur. Concevez des interactions claires plutôt qu'intelligentes et les utilisateurs suivront, conseille Google Design

Google Chrome apporte des modifications à l'interface utilisateur de son navigateur, les changements sont disponibles sur Chrome Canary

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 31/10/2019 à 22:44
Le mec trouve XML plus adapter que JSON parce que son équipe vient de créer un UI Engine qui prend du XML pour faire du rendue dynamique/interprété, c'est tout, il n'y a pas à débattre 3 ans.

Chacun peut bien utiliser l'outil qui convient le mieux à son projet.

P.S. : Et dire qu'en 95 on utilisés principalement Delphi pour définir une interface en "client lourd"*.
C'était typer, compiler et juste ça fonctionnait bien.
Maintenant les gens utilise XML/JSON/YAML/...etc pour décrire leurs interfaces et interpréter le contenue à chaque utilisation.
Je vois ça comme une régression, pas un progrès.

* Vous remarquerez le "client lourd" entre guillemet parce qu’un client léger de 2019 pèse facile dans les 100-200MB.
5  0 
Avatar de Kulvar
Membre éclairé https://www.developpez.com
Le 31/10/2019 à 15:29
JSON n'est pas faire pour présenter les données.
XML (et HTML) si, encore heureux qu'il soit meilleur à ça.
5  1 
Avatar de kbadache
Membre averti https://www.developpez.com
Le 31/10/2019 à 17:13
Citation Envoyé par Pyramidev  Voir le message
Ce serait bien de citer plus d'exemples de l'article original.

Exemple où JSON bat XML

Code propre en JSON :
Code JSON : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  
[ 
  { 
    "first_name": "Michael", 
    "last_name": "Scott", 
    "favorite_movies": [ "Diehard", "Threat Level Midnight" ] 
  }, 
  { 
    "first_name": "Dwight", 
    "last_name": "Schrute", 
    "favorite_movies": [ "The Crow", "Wedding Crashers" ] 
  }, 
  { 
    "first_name": "Pam", 
    "last_name": "Beesly", 
    "favorite_movies": [ "Legally Blonde" ] 
  } 
]

Code naze en XML : on encode une liste à la main avec la virgule comme séparateur.
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  
<Users> 
  <User 
    first="Michael" 
    last="Scott" 
    favoriteMovies="Diehard, Threat Level Midnight" /> 
  <User 
    first="Dwight" 
    last="Schrute" 
    favoriteMovies="The Crow, Wedding Crashers" /> 
  <User 
    first="Pam" 
    last="Beesly" 
    favoriteMovies="Legally Blonde" /> 
</Users>
Attention ! Comment gérer le cas où un titre de film contient une virgule ? Il n'y avait pas besoin de gérer ce cas dans le JSON précédent.

Code correct mais verbeux en XML :
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  
<Users> 
  <User first="Michael" last="Scott"> 
    <Movie>Diehard</Movie> 
    <Movie>Threat Level Midnight</Movie> 
  </User> 
  <User first="Dwight" last="Schrute"> 
    <Movie>The Crow</Movie> 
    <Movie>Wedding Crashers</Movie> 
  </User> 
  <User first="Pam" last="Beesly"> 
    <Movie>Legally Blonde</Movie> 
  </User> 
</Users>
Là, le JSON était meilleur, car plus lisible.

Exemple où XML bat JSON

Arborescence concise en XML :
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
  
<Employee name="Michael Scott" title="Regional Manager"> 
  <Employee name="Dwight Schrute" title="Ass. Regional Mgr" /> 
  <Employee name="Jim Halpert" title="Head of Sales"> 
    <Employee name="Andy Bernard" title="Sales Rep" /> 
    <Employee name="Phyllis Lapin" title="Sales Rep" /> 
  </Employee> 
  <Employee name="Pam Beesly" title="Office Administrator" /> 
</Employee>

Arborescence en JSON, plus verbeuse à cause de l'indentation canonique :
Code JSON : Sélectionner tout
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
  
{ 
  "name": "Michael Scott", 
  "title": "Regional Manager", 
  "reports": [ 
    { 
      "name": "Dwight Schrute", 
      "title": "Ass. Regional Mgr" 
    }, 
    { 
      "name": "Jim Halpert", 
      "title": "Head of Sales", 
      "reports": [ 
        { 
          "name": "Andy Bernard", 
          "title": "Sales Rep" 
        }, 
        { 
          "name": "Phyllis Lapin", 
          "title": "Sales Rep" 
        } 
      ] 
    }, 
    { 
      "name": "Pam Beesly", 
      "title": "Office Administrator" 
    } 
  ] 
}


Sauf que dans tes exemples tu mélanges données et meta-données.
En xml, les attributs sont fait pour les méta-données, les données sont dans les balises, mais ça devient plus verbeux que du json.
En json, il n'est pas possible d'avoir des méta-données.
4  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 31/10/2019 à 16:22
Ce serait bien de citer plus d'exemples de l'article original.

Exemple où JSON bat XML

Code propre en JSON :
Code JSON : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  
[ 
  { 
    "first_name": "Michael", 
    "last_name": "Scott", 
    "favorite_movies": [ "Diehard", "Threat Level Midnight" ] 
  }, 
  { 
    "first_name": "Dwight", 
    "last_name": "Schrute", 
    "favorite_movies": [ "The Crow", "Wedding Crashers" ] 
  }, 
  { 
    "first_name": "Pam", 
    "last_name": "Beesly", 
    "favorite_movies": [ "Legally Blonde" ] 
  } 
]

Code naze en XML : on encode une liste à la main avec la virgule comme séparateur.
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  
<Users> 
  <User 
    first="Michael" 
    last="Scott" 
    favoriteMovies="Diehard, Threat Level Midnight" /> 
  <User 
    first="Dwight" 
    last="Schrute" 
    favoriteMovies="The Crow, Wedding Crashers" /> 
  <User 
    first="Pam" 
    last="Beesly" 
    favoriteMovies="Legally Blonde" /> 
</Users>
Attention ! Comment gérer le cas où un titre de film contient une virgule ? Il n'y avait pas besoin de gérer ce cas dans le JSON précédent.

Code correct mais verbeux en XML :
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  
<Users> 
  <User first="Michael" last="Scott"> 
    <Movie>Diehard</Movie> 
    <Movie>Threat Level Midnight</Movie> 
  </User> 
  <User first="Dwight" last="Schrute"> 
    <Movie>The Crow</Movie> 
    <Movie>Wedding Crashers</Movie> 
  </User> 
  <User first="Pam" last="Beesly"> 
    <Movie>Legally Blonde</Movie> 
  </User> 
</Users>
Là, le JSON était meilleur, car plus lisible.

Exemple où XML bat JSON

Arborescence concise en XML :
Code XML : Sélectionner tout
1
2
3
4
5
6
7
8
9
  
<Employee name="Michael Scott" title="Regional Manager"> 
  <Employee name="Dwight Schrute" title="Ass. Regional Mgr" /> 
  <Employee name="Jim Halpert" title="Head of Sales"> 
    <Employee name="Andy Bernard" title="Sales Rep" /> 
    <Employee name="Phyllis Lapin" title="Sales Rep" /> 
  </Employee> 
  <Employee name="Pam Beesly" title="Office Administrator" /> 
</Employee>

Arborescence en JSON, plus verbeuse à cause de l'indentation canonique :
Code JSON : Sélectionner tout
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
  
{ 
  "name": "Michael Scott", 
  "title": "Regional Manager", 
  "reports": [ 
    { 
      "name": "Dwight Schrute", 
      "title": "Ass. Regional Mgr" 
    }, 
    { 
      "name": "Jim Halpert", 
      "title": "Head of Sales", 
      "reports": [ 
        { 
          "name": "Andy Bernard", 
          "title": "Sales Rep" 
        }, 
        { 
          "name": "Phyllis Lapin", 
          "title": "Sales Rep" 
        } 
      ] 
    }, 
    { 
      "name": "Pam Beesly", 
      "title": "Office Administrator" 
    } 
  ] 
}
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 31/10/2019 à 20:16
Un des avantages de JSON sur XML est qu'il est plus facile à lire par un programme.
Pour la lecture par un humain, comme l'a montré l'auteur de l'article original, ça dépend des cas.

J'en profite pour souligner que, parmi les formats les plus utilisés pour structurer des données arbitraires, il y a aussi le YAML qui est une extension du JSON qui, par rapport à JSON, est plus facile à lire par un humain, mais moins facile à lire pour un programme.

Prenons l'exemple du JSON suivant :
Code JSON : Sélectionner tout
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
{ 
  "name": "Michael Scott", 
  "title": "Regional Manager", 
  "reports": [ 
    { 
      "name": "Dwight Schrute", 
      "title": "Ass. Regional Mgr" 
    }, 
    { 
      "name": "Jim Halpert", 
      "title": "Head of Sales", 
      "reports": [ 
        { 
          "name": "Andy Bernard", 
          "title": "Sales Rep" 
        }, 
        { 
          "name": "Phyllis Lapin", 
          "title": "Sales Rep" 
        } 
      ] 
    }, 
    { 
      "name": "Pam Beesly", 
      "title": "Office Administrator" 
    } 
  ] 
}

Voici une réécriture en YAML :
Code YAML : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
name: Michael Scott 
title: Regional Manager 
reports: 
  - name: Dwight Schrute 
    title: Ass. Regional Mgr 
  - name: Jim Halpert 
    title: Head of Sales 
    reports: 
      - name: Andy Bernard 
        title: Sales Rep 
      - name: Phyllis Lapin 
        title: Sales Rep 
  - name: Pam Beesly 
    title: Office Administrator
1  0 
Avatar de LeBressaud
Membre confirmé https://www.developpez.com
Le 01/11/2019 à 0:53
Citation Envoyé par Sodium Voir le message
Je dirais même l'inverse, JSON contient essentiellement des meta-données.
Sur un forum ça passe presque inaperçu, évite de dire ça en réunion avec des gens qui s'y connaisse un minimum..

JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu. Aucun rapport avec des méta-données
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 01/11/2019 à 2:11
Citation Envoyé par LeBressaud Voir le message
JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu.
JSON distingue plusieurs types de données. Par exemple, les booléens ne sont pas des nombres qui ne sont pas des chaînes.
De base, dans du JSON, tout comme dans du XML, on peut mettre n'importe quoi n'importe comment.
Et si on veut écrire un schéma de validation pour restreindre ce que l'on a le droit d'écrire, tout comme il existe des schémas XML, il existe aussi des schémas JSON.
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 01/11/2019 à 14:04
Citation Envoyé par Sodium  Voir le message
JSON permet de faire ce que l'on veut, rien ne t'empêche de créer une clé metadata

Je suis d'accord avec ce passage.

Citation Envoyé par Sodium  Voir le message
Je dirais même l'inverse, JSON contient essentiellement des meta-données.

Avoir plus de meta-données que de données serait bizarre. Les données normales, ce sont les données principales que l'on veut stocker. Les meta-données, ce sont des informations complémentaires. Et il n'y a aucune raison qu'il y en ait plus en JSON qu'en XML.

Citation Envoyé par kbadache  Voir le message
Sauf que dans tes exemples tu mélanges données et meta-données.
En xml, les attributs sont fait pour les méta-données, les données sont dans les balises, mais ça devient plus verbeux que du json.

Au début de l'article original, on peut lire :
When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:

“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”

L'auteur défend le XML en indiquant qu'il y a des cas où on peut le rendre plus lisible que le JSON.
Sauf que, dans les cas où le XML peut être plus lisible que le JSON, il faut tirer profit des attributs.
Si on réserve les attributs aux méta-données, alors on se retrouve avec du XML très verbeux comme ça :
Code XML : Sélectionner tout
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
<?xml version="1.0" encoding="UTF-8" ?> 
<root> 
  <name>Michael Scott</name> 
  <title>Regional Manager</title> 
  <reports> 
    <name>Dwight Schrute</name> 
    <title>Ass. Regional Mgr</title> 
  </reports> 
  <reports> 
    <name>Jim Halpert</name> 
    <title>Head of Sales</title> 
    <reports> 
      <name>Andy Bernard</name> 
      <title>Sales Rep</title> 
    </reports> 
    <reports> 
      <name>Phyllis Lapin</name> 
      <title>Sales Rep</title> 
    </reports> 
  </reports> 
  <reports> 
    <name>Pam Beesly</name> 
    <title>Office Administrator</title> 
  </reports> 
</root>
Et là, on donne raison aux détracteurs inconditionnels du XML : pourquoi choisir encore ce vieux format obsolète plus difficile à lire que du JSON, à la fois pour un humain et pour un programme ?
Code JSON : Sélectionner tout
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
{ 
  "name": "Michael Scott", 
  "title": "Regional Manager", 
  "reports": [ 
    { 
      "name": "Dwight Schrute", 
      "title": "Ass. Regional Mgr" 
    }, 
    { 
      "name": "Jim Halpert", 
      "title": "Head of Sales", 
      "reports": [ 
        { 
          "name": "Andy Bernard", 
          "title": "Sales Rep" 
        }, 
        { 
          "name": "Phyllis Lapin", 
          "title": "Sales Rep" 
        } 
      ] 
    }, 
    { 
      "name": "Pam Beesly", 
      "title": "Office Administrator" 
    } 
  ] 
}
1  0 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 31/10/2019 à 14:46
Heu ben oui... idéalement avec du XML itérant sur des données JSON d'ailleurs comme c'est le cas d'Angular ou Vuejs (je ne parlerai pas de React car c'est sale).

Il y avait un doute à ce sujet ?
0  0 
Avatar de pdeville
Membre à l'essai https://www.developpez.com
Le 31/10/2019 à 18:42
JSon est parfaitement adapté à la gestion des données structurées et fournit un format peu verbeux.

XML bien que plus verbeux permet de representer des données non structurérs avec CDATA.
0  0