Commentaires

L'objet de l'article était de faire le lien entre XSL/XML et framework JS/JSON justement. Je ne crois pas que ça soit si "clair" parfois, notamment lorsque je vois l'orientation de Vue.js justement, où les transformations sont faites côté client en JS. Quant aux autres framework, notamment l'utilisation d'un DOM virtuel, cela me semble justement fantastiquement compliqué pour pas grand chose. Et finalement pas très efficace.

Derrière, c'est bien la question de la pertinence des outils qui se posent.

Effectivement les commentaires se recoupent mais il restait quelques incompréhensions...

Envoyé par SylvainPV

Mais tout le monde est d'accord avec toi: pour du gabarit de site, du template, de la structure du document, on utilise encore et toujours du HTML ou d'autres langages dérivés du XML. Rien n'a changé avec les frameworks JavaScript modernes, même JSX peut être considéré comme un dérivé de XML à la limite. Utiliser JSON ou une structure JS pour ça, à la manière de domjs, est complètement marginal et pas pratique du tout.

En revanche, ça fait longtemps que JSON a remplacé XML dans le transit de données pures. Historiquement le X de AJAX est pour XML mais dans les faits, c'est du JSON qui circule en AJAX la plupart du temps. C'est normal, toutes les web app modernes manipulent les données en JS pour composer les vues côté client ; et JSON est bien plus facile à parser et manipuler en JS qu'un arbre XML.

C'est pour ça que je ne comprends pas le débat, les deux langages coexistent et sont à leur place naturelle depuis des années. Les frameworks n'ont pas changé cet état de fait.

Quand tu as une valeur JSON, tu la lis facilement et celle-ci peut contenir d'autres valeurs. En gros, un document JSON, c'est un tableau - ou dictionnaire, ou marginalement une string seule -, qui contient d'autres valeurs, etc.

Pour rejoindre l'aspect XML et par convention (j'insiste là dessus : une convention dépend de l'implémentation), tu indiques que telle clé va contenir des attributs et le reste est l'arborescence. Ainsi pour chaque élément, c'est une cascade de tableaux :

Code json :

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

1
2
3
4
5
{"arbre": { 
"_att" : { "id": "truc", "style": "yenapas" }, 
"item1": { "_att" : { "id": "machin", "style": "yenatoujourspas" }, 
...
}}

Sur une page complète, tu aurais donc l'imbrication de dizaines de tableau les uns dans les autres. Pour du gabarit de site (qu'est l'objet de l'article initialement), et encore une fois non pas pour passer une variable à la volée ou du texte, ou quelques choses qui ne soit pas une arborescence complexe, XML est davantage adapté que JSON. Quand aux attributs, XML les gère nativement et donc tu n'as pas à te soucier d'avoir des clés différentes pour les stocer en fonction de l'outil utilisé : le XML cadre ces sujets nativement.

Pour une arborescence complexe, c'est plus simple à lire (à mon sens j'en conviens) et à maintenir quelque chose de léger :

Code xml :

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

1
2
3
4
5
 
<arbre id="truc" style="yenapas"> 
<item id="machin" style="yenatoujourspas" /> 
...
</arbre>

Le problème a été de confondre à mon sens le transport de données simples - où est plus performant JSON - à des données d'arborescence complexe, dont hérite le DOM du navigateur. Je ne dis pas que XML est supérieur partout, mais pour une structure de page web, c'est tout de même le plus adapté car le plus proche de ce qui sera fait.

De fait les transformations XSL sur le XML découle de ce constat (traiter du XML par l'outil le plus adapté pour générer un HTML) et XSL est géré par du binaire sur une navigateur -> c'est infiniment plus rapide que de charger un JS qui va traiter du JSON. D'où ma remarque initiale sur WebAssembly, qui vient virer JS qui est particulièrement lent (d'où son orientation de plus en plus asynchrone pour résoudre la problématique de performance) pour la suite de ce que saurait être le web.

Je ne sais pas si je suis plus clair mais j'ai essayé

Envoyé par SylvainPV

Je ne comprends pas bien l'intérêt du débat XML vs JSON. Quand il s'agit de structure de document, on utilise toujours HTML ou autre langage de balisage parce qu'ils sont conçus pour. Et quand il s'agit de données, on utilise JSON parce que c'est plus léger et plus facile à parser en JS.


Je ne saisis pas bien ce que tu veux dire par "à proportion égale", mais gageons que pour une même structure de données, sa représentation en JSON sera toujours plus légère que sa représentation en XML. Je veux bien qu'on me montre un contre-exemple.

@Lcf.js: je pense au contraire que le généré côté client présente un avantage énergétique. La migration d'une appli utilisant des JSP vers une single page app et API REST s'est traduite par une grosse diminution du trafic réseau. Comme les vues et la logique sont complètement décorélées des données, on peut les mettre en cache plus longtemps et plus efficacement. Seules les données circulent sur le réseau et sous la forme la plus légère possible. Certes les vues sont générées côté client et JavaScript consomme un peu, mais les échanges réseau consomment encore plus sur un mobile. Et c'est sans compter les gains sur toute la chaîne du client jusqu'au serveur, qui mis bout à bout doivent compter beaucoup également. En revanche, un site statique sera effectivement moins énergivore si on met en cache les pages complètes. Mais faire un site statique avec un framework JS, c'est aussi gâcher l'énergie du développeur

Je ne comprends pas bien l'intérêt du débat XML vs JSON. Quand il s'agit de structure de document, on utilise toujours HTML ou autre langage de balisage parce qu'ils sont conçus pour. Et quand il s'agit de données, on utilise JSON parce que c'est plus léger et plus facile à parser en JS.

Bien sûr que XML est verbeux : à proportion égale, il contient bien plus de données

Je ne saisis pas bien ce que tu veux dire par "à proportion égale", mais gageons que pour une même structure de données, sa représentation en JSON sera toujours plus légère que sa représentation en XML. Je veux bien qu'on me montre un contre-exemple.

@Lcf.js: je pense au contraire que le généré côté client présente un avantage énergétique. La migration d'une appli utilisant des JSP vers une single page app et API REST s'est traduite par une grosse diminution du trafic réseau. Comme les vues et la logique sont complètement décorélées des données, on peut les mettre en cache plus longtemps et plus efficacement. Seules les données circulent sur le réseau et sous la forme la plus légère possible. Certes les vues sont générées côté client et JavaScript consomme un peu, mais les échanges réseau consomment encore plus sur un mobile. Et c'est sans compter les gains sur toute la chaîne du client jusqu'au serveur, qui mis bout à bout doivent compter beaucoup également. En revanche, un site statique sera effectivement moins énergivore si on met en cache les pages complètes. Mais faire un site statique avec un framework JS, c'est aussi gâcher l'énergie du développeur

Pour ceux qui sont intéressés, j'ai continué mes "recherches" afin de prendre en compte vos différents retours et me remettre en question... question de caractère !

Pour ceux qui répugnent au XML par sa nature, pas grand chose à faire : une question de goût et d'opportunités.

Pour ceux par contre qui y trouvent davantage de défauts que de qualité et n'y sont pas totalement réfractaires, un article sur les avancées XSLT 2 et 3 est disponible et très accessible :
https://www.xml.com/articles/2017/02...using-xslt-30/

Le nombre de fonctions désormais nativement supportés en très forte augmentation, l'approfondissement de certains concepts (multi-arborescences, transformation depuis et vers CSV ou JSON, etc), ainsi que l'amélioration globale des performances devraient retenir notre attention.

A la suite de nos échanges et de mes lectures, je reste persuadé que XSL pourrait devenir à la longue un langage de pré-processing pour le gabarit et les opérations de base dans certains contextes très courants...

Merci à tous !

Malheureusement les applications web ne sont pas encore rentrées dans l'ère moderne. Il y a 20 ans j'étais persuadé que le javascript serait mort et enterré et que des langages modernes associés à de véritables API orientées composant verrai le jour pour construire nos future application web et ... je me suis trompé !

Pourquoi 20 ans plus tard est ton encore à chercher comment coder un bête tableau navigable et triable ? Pourquoi chercher encore certains composants de base comme les sliders ? Pourquoi faire du routage de page est encore aussi compliqué ? etc ... Faire une appli web consiste encore à faire de la cuisine et le plus souvent a faire fonctionner des composants non standards qui reposent parfois sur des technologie concurrentes. Je me rappelle au siècle précedent ou débutant sous Lotus Notes et Java je ne me posait pas toutes ces questions car j'avais a disposition toutes la richesse des composants de la plateforme pour faire à la fois du client serveur ou du web. Toute l’énergie était alors dédiée pour implementation du métier au coeur de l'application et non la mise au point des composants de base.

La conséquence est que le coût des projets a explosé alors que la complexité des IHM n'a quasiment pas progressé.

Malheureusement les applications web ne sont pas encore rentrées dans l'ère moderne. Il y a 20 ans j'étais persuadé que le javascript serait mort et enterré et que des langages modernes associés à de véritables API orientées composant verrai le jour pour construire nos future application web et ... je me suis trompé !

Pourquoi 20 ans plus tard est ton encore à chercher comment coder un bête tableau navigable et triable ? Pourquoi chercher encore certains composants de base comme les sliders ? Pourquoi faire du routage de page est encore aussi compliqué ? etc ... Faire une appli web consiste encore à faire de la cuisine et le plus souvent a faire fonctionner des composants non standards qui reposent parfois sur des technologie concurrentes. Je me rappelle au siècle précedent ou débutant sous Lotus Notes et Java je ne me posait pas toutes ces questions car j'avais a disposition toutes la richesse des composants de la plateforme pour faire à la fois du client serveur ou du web. Toute l’énergie était alors dédiée pour implementation du métier au coeur de l'application et non la mise au point des composants de base.

La conséquence est que le coût des projets a explosé alors que la complexité des IHM n'a quasiment pas progressé.

En JSON par contre, va recherche facilement un ID particulier dans une arborescence complexe... pas si évident. Il n'y a pas par exemple de querySelector, etc.

Par défaut non mais tu trouveras facilement des librairies JS capables d'imiter notamment Linq de .net pour faire du requêtage sur des objets JSON. Et là c'est beaucoup plus simple et puissant que du querySelector.

Exemple : https://github.com/neuecc/linq.js

Envoyé par Nothus

(1) Effectivement, le coût est astronomique en terme énergétique pour le rendu du code. Cela dit, en termes économiques car c'est par eux que le monde est monde quoiqu'on en pense :
- "petit" projet : mieux vaut faire "ramer" un téléphone portable de client que d'encombrer mon serveur mutualisé ;
- "gros" projet : un miliseconde de gagnée côté client c'est +200 clients / heures dans le monde, alors je rajoute X serveurs / RAM / trucs divers.

-> la question du coût est étroitement liée à celle du projet. Le curseur n'est pas toujours tout client ou tout serveur.

L'aspect énergétique n'est pas le seul, certes, mais il devrait primer sur l'économique. Sérieusement, si ton projet, quelle qu'en soit sa taille, commence à faire ramer ton serveur, optimise et change/ajoute de(s) serveur(s), ça a un coût anecdotique par rapport à ce que ça rapporte et par rapport à l'économie que tes utilisateurs feront.

Envoyé par Nothus

(2) C'est marrant parce que ta solution ressemble (prisme déformant de ma part ?) à ce que j'évoque : la différence c'est que désormais un pré-cache ou un cache local - peu importe son nom - existe en Javascript et qu'il peut servir avec les Workers pour traiter et fournir une forme de service de rendu local. Afin d'éviter tout le re-calcul justement et les va-et-viens vers le serveur. C'est ma notion de "fragment" de l'article, pour ensuite remplacer ça et là dans la page actuelle ou future des portions du DOM. Qu'en penses-tu ?

En fait, la notion de fragments, j'en use et abuse... mais pas en embarqué, directement dans la page (en display none ou en templates), cela alourdit les pages en question, même si l'utilisateur n'en a pas besoin, cela nuit au référencement et cela peut poser des problèmes de cache utilisateur.

À la place, je laisse le serveur fournir ces fragments, tout en lui laissant le contrôle du comportement du site ou de l'application, car le déportage vers le poste client pose un autre problème : la segmentation de l'intelligence logicielle.

Envoyé par Nothus

(3) Sur les performances JSON/XML, je suis moins convaincu. Parce que JSON pour produire un code HTML correct, a quand même besoin d'un framework qui tourne bien. XML et ses transformations, c'est natif -> on passe d'une logiciel de développement projet à celui de l'utilisation des ressources propres et bien plus rapide (C/C++, etc) du navigateur.

Sur l'aspect des performances, je ne parlais que de celles de build/parsing de la structure.

Envoyé par Nothus

Je propose justement de revenir à des choses plus simples : sérialiser les objets à afficher, ne pas partir à charger jQuery parce que c'est l'habitude pour quelques petits trucs à faire en JS, éviter de construire des listes complexes en pseudo-JS dans du code HTML qui va demande 100 ko de bibliothèque pour être traité, etc...

Revenons encore à plus simple : éviter de sérialiser des objets... zieute les démos et sources de démos d'anticore, tu verras la légèreté et la simplicité du développement front, le tout, sans charger un dinosaure obèse du genre de jquery, même si un jour anticore devenait une bibliothèque pesant des To de données... ton dist ne contient que ce que tu utilises réellement.

Je nie pas les inconvénients du XML... je dénonçais un peu le fait qu'on trouve trop souvent que des avantages au JSON, d'une manière parfois déraisonnable.

YAML : ouaip, on approche du meilleur des deux mondes - même si ça reste perfectible.

Envoyé par psychadelic

Pour ce que ça vaut...
XML / XSL, j'en ai soupé; c a été une sorte de rêve fantasmé d'une informatique de partage, etc, et c'est en fait un vrai cauchemar.

JSON,, ben c'est pas les mêmes ambitions, déjà, à utiliser pour des infos utiles, des micro_format à la limite.

Mais maintenant, je commence à lorgner du coté de YAML, question de lisibilité

Complètement d'accord avec toi : c'est la facilité de se dire "aller, j'ai plein de RAM et mes clients aussi, faisons n'importe quoi". La baisse du coût matériel a eu un impact non pas sur la qualité du code - il évolue dans sa pratique et dépend de celui qui l'écrit -, mais sur la superposition des couches que tu évoques.

Je propose justement de revenir à des choses plus simples : sérialiser les objets à afficher, ne pas partir à charger jQuery parce que c'est l'habitude pour quelques petits trucs à faire en JS, éviter de construire des listes complexes en pseudo-JS dans du code HTML qui va demande 100 ko de bibliothèque pour être traité, etc...

Comme on peut se poser l'opportunité des nombreuses, trop nombreuses requêtes et bibliothèques pour le suivi commercial : la lourdeur des pages c'est le combat de nos politiques de sécurité et de confidentialité locale, du peu de cas des développeurs et chargés de projets pour le respect des navigateurs clients ou du suivi au pixel près le curseur de ce même client. Business as usual...

Pour Canvas et autres effectivement, suite logique. Je dirais même que j'attends avec impatient les WebAssembly pour que les WebApp ne soient pas juste "une grosse page disponible hors ligne" et la possibilité d'accès au disque client, à d'autres type de bases de données (jamais compris pourquoi on tapait autant sur WebSQL), etc.

Mais lorsque le rendu se fera majoritairement par là, beaucoup de développeur qui n'ont jamais quitté leur JS adoré vont avoir mal...

Envoyé par eclesia

Puisse que le ton est au lacher prise, j'offre mon point de vue.

Le Web d'aujourd'hui, que ce soit JSON ou XML/HTML est comme un tracteur, des couches par dessus des couches et encore des couches.
Plus les PC vont vite et ont de la mémoire et plus on en rajoute !
50-100Mo par onglet pour afficher meme une bete page static, c'est n'importe quoi.
Les specs HTML/CSS/WebSocket/etc... sont monstrueuses, nombreuses constament changeantes et bonnes a jeter.

Il faut redescendre plus bas dans les strates, fournir des API simples pour faire des vrai programmes pas des bidouilles, car oui il faut le dire le web dynamique c'est de la bidouille.

La direction a prendre est celle de Zebkit : http://repo.zebkit.org/latest/samples/uidemo.html
On s'appuie sur une API de dessin type Canvas ou OpenVG et on dessine, fin de l'histoire.
Libre a ceux qui aime JSON ou XML de faire leur bibliotheques de widget avec l'un ou l'autre.
Fini HTML, fini CSS, fini Javascript, du bytecode (type webassembly++) et des API, bref une VM.

Combien de temps encore va-t-on encore trainer tous ce foutoir...

Ton PS est fort à propos effectivement ! Pas la peine de rajouter de la complexité sans nécessité. Pour les objets vraiment pointus, ni JSON ni XML ne seront le plus adapté quoiqu'on fasse : pour moi je mets une limite à ce deux langues de présentation des données à des choses communes (pas de streams, etc). Je reconnais juste à XML une capacité plus fine dans le type de variable stockée (d'où mon insistance sur les attributs) ainsi qu'une utilisation commune des méthodes du DOM (qui sont pas si mal que ça).

En JSON par contre, va recherche facilement un ID particulier dans une arborescence complexe... pas si évident. Il n'y a pas par exemple de querySelector, etc.

Par contre je te rejoins sur la taille (moins sur la lisibilité : question d'habitude, j'ai tendance à lire aussi facilement les deux) : le JSON gagne clairement la partie.

Envoyé par stailer

J'ai pas lu tout l'article mais au sujet des attributs XML, et pour répondre à la question :

Réponse :

Tout simplement car la plupart du temps le résultat JSON correspond à un objet côté code (classe PHP, C#, JS.. etc).
Une structure de classe, en dehors de ses méthodes et constantes, contient : des propriétés à typage simple, complexe ou des tableaux d'autres objets.

Donc : le XML à travers ses attributs rend complexe la chose. En .net pas de souci, les [XmlAttribute] fournis permettent de dire si c'est l'élément ou l'attribut qui correspond à une propriété de classe donnée... Mais pas forcément aussi simplement dans d'autres langages... Et dans tous les cas ça n'est pas vraiment pratique. Les éléments XML sont pénibles à lire..

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<monTableau>
   <monItem>
        <monNom>moi</monNom>
       <monElement>28</monElement>
   </monItem>
  <monItem>
       <monNom>toi</monNom>
       <monElement>12</monElement>
   </monItem>
</monTableau>

Sera quoi qu'on en dise toujours plus pénible que :

Code :

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

1
2
3
4
5
{ monTableau : [
     { monNom : "toi" , monElement : 28 },
     { monNom : "moi" , monElement : 12 },
]}

A noter aussi que pour un appel HTTP le flux JSON sera plus petit et donc performant qu'un flux XML.

Pour le reste.. A chacun sa façon de voir les choses et de coder quand il a la chance de pouvoir décider


PS : comme je le sens arriver, oui je sais qu'on pouvait faire :

Code :

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

1
2
3
4
5
<monTableau>
   <monItem monNom="moi" monElement="28" />
    <monItem monNom="toi" monElement="12" />
</monTableau>

C'est un peu plus simple en effet... Mais seules des types très simples seront "stockables" de cette manière. Après il faudra passer par l'élément et mixer les 2 méthodes.. Pas sûr que ce soit très propre au final.

(1) Effectivement, le coût est astronomique en terme énergétique pour le rendu du code. Cela dit, en termes économiques car c'est par eux que le monde est monde quoiqu'on en pense :
- "petit" projet : mieux vaut faire "ramer" un téléphone portable de client que d'encombrer mon serveur mutualisé ;
- "gros" projet : un miliseconde de gagnée côté client c'est +200 clients / heures dans le monde, alors je rajoute X serveurs / RAM / trucs divers.

-> la question du coût est étroitement liée à celle du projet. Le curseur n'est pas toujours tout client ou tout serveur.

(2) C'est marrant parce que ta solution ressemble (prisme déformant de ma part ?) à ce que j'évoque : la différence c'est que désormais un pré-cache ou un cache local - peu importe son nom - existe en Javascript et qu'il peut servir avec les Workers pour traiter et fournir une forme de service de rendu local. Afin d'éviter tout le re-calcul justement et les va-et-viens vers le serveur. C'est ma notion de "fragment" de l'article, pour ensuite remplacer ça et là dans la page actuelle ou future des portions du DOM. Qu'en penses-tu ?

(3) Sur les performances JSON/XML, je suis moins convaincu. Parce que JSON pour produire un code HTML correct, a quand même besoin d'un framework qui tourne bien. XML et ses transformations, c'est natif -> on passe d'une logiciel de développement projet à celui de l'utilisation des ressources propres et bien plus rapide (C/C++, etc) du navigateur.

Envoyé par Lcf.vs

Le JSON a un avantage indéniable sur le XML, les performances !

Par contre, quelle que soit la méthode, dès que c'est du généré côté client, cela a un coût énergétique astronomique !

En effet, chaque utilisateur va utiliser de l'énergie pour générer chaque noeud, sans bénéficier de cache serveur, ni cache navigateur.

En revanche, le stateless côté client n'a pas trop de sens.

C'est pourquoi dans ma suite de frameworks, j'ai un webservice (avec qui j'interagis en JSON ou en XML, selon un header) et en façades de ce webservice, j'ai des serveurs de rendu qui, eux, s'occupent de la gestion de vraies sessions (liées à un stateless token), du cache, etc.

Côté client, en JS, je ne fais donc que recevoir des éléments HTML que j'ajoute ou qui en remplacent d'autre, écouter des évènements, ajouter de l'interactivité (UX).

J'étais pourtant un grand fan inconditionnel du tout généré, côté client, il y a près de 10 ans, mais depuis que j'me suis rendu compte des inconvénients, surtout énergétiques, j'en suis revenu.

Puis j'ai imaginé mon anticore et ça a tout simplifié

Pour ce que ça vaut...
XML / XSL, j'en ai soupé; c a été une sorte de rêve fantasmé d'une informatique de partage, etc, et c'est en fait un vrai cauchemar.

JSON,, ben c'est pas les mêmes ambitions, déjà, à utiliser pour des infos utiles, des micro_format à la limite.

Mais maintenant, je commence à lorgner du coté de YAML, question de lisibilité

Puisse que le ton est au lacher prise, j'offre mon point de vue.

Le Web d'aujourd'hui, que ce soit JSON ou XML/HTML est comme un tracteur, des couches par dessus des couches et encore des couches.
Plus les PC vont vite et ont de la mémoire et plus on en rajoute !
50-100Mo par onglet pour afficher meme une bete page static, c'est n'importe quoi.
Les specs HTML/CSS/WebSocket/etc... sont monstrueuses, nombreuses constament changeantes et bonnes a jeter.

Il faut redescendre plus bas dans les strates, fournir des API simples pour faire des vrai programmes pas des bidouilles, car oui il faut le dire le web dynamique c'est de la bidouille.

La direction a prendre est celle de Zebkit : http://repo.zebkit.org/latest/samples/uidemo.html
On s'appuie sur une API de dessin type Canvas ou OpenVG et on dessine, fin de l'histoire.
Libre a ceux qui aime JSON ou XML de faire leur bibliotheques de widget avec l'un ou l'autre.
Fini HTML, fini CSS, fini Javascript, du bytecode (type webassembly++) et des API, bref une VM.

Combien de temps encore va-t-on encore trainer tous ce foutoir...

J'ai pas lu tout l'article mais au sujet des attributs XML, et pour répondre à la question :

Alors pourquoi ne pas directement utiliser du XML dont hérite le HTML fut-il de version 4 ou 5... ?

Réponse :

Tout simplement car la plupart du temps le résultat JSON correspond à un objet côté code (classe PHP, C#, JS.. etc).
Une structure de classe, en dehors de ses méthodes et constantes, contient : des propriétés à typage simple, complexe ou des tableaux d'autres objets.

Donc : le XML à travers ses attributs rend complexe la chose. En .net pas de souci, les [XmlAttribute] fournis permettent de dire si c'est l'élément ou l'attribut qui correspond à une propriété de classe donnée... Mais pas forcément aussi simplement dans d'autres langages... Et dans tous les cas ça n'est pas vraiment pratique. Les éléments XML sont pénibles à lire..

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<monTableau>
   <monItem>
        <monNom>moi</monNom>
       <monElement>28</monElement>
   </monItem>
  <monItem>
       <monNom>toi</monNom>
       <monElement>12</monElement>
   </monItem>
</monTableau>

Sera quoi qu'on en dise toujours plus pénible que :

Code :

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

1
2
3
4
5
{ monTableau : [
     { monNom : "toi" , monElement : 28 },
     { monNom : "moi" , monElement : 12 },
]}

A noter aussi que pour un appel HTTP le flux JSON sera plus petit et donc performant qu'un flux XML.

Pour le reste.. A chacun sa façon de voir les choses et de coder quand il a la chance de pouvoir décider


PS : comme je le sens arriver, oui je sais qu'on pouvait faire :

Code :

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

1
2
3
4
5
<monTableau>
   <monItem monNom="moi" monElement="28" />
    <monItem monNom="toi" monElement="12" />
</monTableau>

C'est un peu plus simple en effet... Mais seules des types très simples seront "stockables" de cette manière. Après il faudra passer par l'élément et mixer les 2 méthodes.. Pas sûr que ce soit très propre au final.

Le JSON a un avantage indéniable sur le XML, les performances !

Par contre, quelle que soit la méthode, dès que c'est du généré côté client, cela a un coût énergétique astronomique !

En effet, chaque utilisateur va utiliser de l'énergie pour générer chaque noeud, sans bénéficier de cache serveur, ni cache navigateur.

En revanche, le stateless côté client n'a pas trop de sens.

C'est pourquoi dans ma suite de frameworks, j'ai un webservice (avec qui j'interagis en JSON ou en XML, selon un header) et en façades de ce webservice, j'ai des serveurs de rendu qui, eux, s'occupent de la gestion de vraies sessions (liées à un stateless token), du cache, etc.

Côté client, en JS, je ne fais donc que recevoir des éléments HTML que j'ajoute ou qui en remplacent d'autre, écouter des évènements, ajouter de l'interactivité (UX).

J'étais pourtant un grand fan inconditionnel du tout généré, côté client, il y a près de 10 ans, mais depuis que j'me suis rendu compte des inconvénients, surtout énergétiques, j'en suis revenu.

Puis j'ai imaginé mon anticore et ça a tout simplifié

J'insiste : comparer JSON et XML pour "confectionner des pages" n'a pas de sens car la finesse dans l'information n'est pas égale. Quand tu parles de structures claires, je te rejoins : sous JSON, ça reste une clé arbitraire comme une autre. L'un va prendre telle clé, un autre une autre.

Je ne nie pas que le JSON peut avoir du sens, mais pas pour construire une page, pour donner sa structure. L'intégration de XML, de ses transformations est natif aux navigateurs. JSON est hérité parce que JS le supporte et que le JS est l'habitude d'usage sur les pages.

Bien sûr que XML est verbeux : à proportion égale, il contient bien plus de données. Quand au débuggage, tu n'as pas plus de difficultés que du JSON où il y aura un caractère manquant. Les logiciels dédiés, s'ils sont bien fichus, indiquent les fautes de grammaire en plus des fautes de syntaxe. Et est-ce si "grave" d'avoir une grammaire respectée ? Ne souffre t-on pas justement d'avoir parfois du HTML qui prend un peu tout et n'importe quoi, qui reste souvent très (trop) laxiste ? Au point que chacun fait son petit hack, à tous les niveaux ?

Sur le transport : change ton API, tu es bon pour garder des anciennes versions le temps d'une migration. L'aspect positif du verbeux, c'est qu'il est aussi compréhensible par l'humain. Que le XML "syntaxique" - c'est-à-dire sans grammaire derrière pour le formalisme de l’arborescence, est parfaitement lisible.

Tu parles de revenir en arrière : je te propose au contraire de comprendre pourquoi on ne sort pas du HTML pour "créer" du Web et pourquoi le HTML est tellement associé au XML.

Quant aux technos, j'en rajoute une fois encore, mais pour la création de page où la plupart du temps et des sites, la page est "statique", c'est vraiment le marteau pour une vis à mon sens.

Envoyé par blbird

Le JSON et le XSL n'ont pas grand chose en commun.

Pour ma part, en ayant fait beaucoup, le XSL est à bannir depuis de nombreuses années : c'est une techno verbeuse, totalement illisible dès qu'on dépassé les quelques dizaines de lignes, aucune possibilité de débogage.

De la même manière, hormis pour décrire un DOM, je privilégié largement le JSON au XML pour le transport de données vers des sites Web. Dans l'écrasante majorité des cas, si ce n'est tous, pas besoin de décrire les données qu'on transporte, une structure claire suffit : économie de taille, de temps de traitement, et même de lisibilité.

Alors de là à combiner XML et XSL pour générer des sites Web, l'ayant déjà expérimenté aussi, je le déconseille fortement. Très très mauvaise expérience sur ces technos.

Je ne vois pas comment on peut conseiller de revenir en arrière sous prétexte que certains utilisent des technologies plus récentes plus ou moins incorrectement.

VUEJS est une des toutes meilleurs techno JS du moment, je le conseille par contre fortement.

Le JSON et le XSL n'ont pas grand chose en commun.

Pour ma part, en ayant fait beaucoup, le XSL est à bannir depuis de nombreuses années : c'est une techno verbeuse, totalement illisible dès qu'on dépassé les quelques dizaines de lignes, aucune possibilité de débogage.

De la même manière, hormis pour décrire un DOM, je privilégié largement le JSON au XML pour le transport de données vers des sites Web. Dans l'écrasante majorité des cas, si ce n'est tous, pas besoin de décrire les données qu'on transporte, une structure claire suffit : économie de taille, de temps de traitement, et même de lisibilité.

Alors de là à combiner XML et XSL pour générer des sites Web, l'ayant déjà expérimenté aussi, je le déconseille fortement. Très très mauvaise expérience sur ces technos.

Je ne vois pas comment on peut conseiller de revenir en arrière sous prétexte que certains utilisent des technologies plus récentes plus ou moins incorrectement.

VUEJS est une des toutes meilleurs techno JS du moment, je le conseille par contre fortement.

Envoyé par danielhagnoul

J'ai écrit une version JS : https://www.developpez.net/forums/bl...100000-0-180s/

J'ai vu Tu as bien fait, c'est important pour souligner / comparer les qualités et défauts de chaque langage et voir si des pistes d'amélioration sont possibles. Juste une question : pour imbriquer tes boucles de récursion ? Une seule avec la gestion des erreurs n'est-elle pas plus pertinente / efficace ?

Pour être honnête, j'ai procéder à tâtons pour arriver à cet article et trouver "ma" solution. J'imagine qu'il doit en exister des plus performantes encore... ?

Enfin je me suis servi de la piste sur les nombres premiers pour un nouvel article récent sur un moteur IFTTT. L'exportation vers JS et notamment NodeJS peut être utile pour une version déchargée vers le client ou encore pour proposer des micro-services à un serveur.

Envoyé par dourouc05

Au fait, pourquoi développer ta propre solution au lieu d'utiliser ce que la bibliothèque standard fournit (argparse avec Python 3 https://docs.python.org/3/library/argparse.html) ?

Parce que ?

Effectivement, beaucoup de choses sont possibles à partir des modules standards. Mon tutoriel (avec un objectif pédagogique, j'ai galéré pour apprendre seul Python) ne présente pas les choses autrement car j'utilise sys.argv qui est bien tiré d'un module standard (sys). D'ailleurs argparse passe le plus clair de sa source à utiliser les données par sys.argv et finalement nous partons tous les deux du même point, pour ne pas arriver tout à fait au même résultat (volontairement).

Voici ce qui me bloque dans la "philosophie" de argparse : "The argparse module makes it easy to write user-friendly command-line interfaces." Le module s'oriente moins - à mon sens - sur ce qui permet de créer un contexte, que de faire le lien entre des commandes (les arguments) et des actions (les fonctions).

L'exemple par défaut de la doc est révélateur :

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
import argparse
 
parser = argparse.ArgumentParser(description='Process some integers.')
parser.add_argument('integers', metavar='N', type=int, nargs='+',
                    help='an integer for the accumulator')
parser.add_argument('--sum', dest='accumulate', action='store_const',
                    const=sum, default=max,
                    help='sum the integers (default: find the max)')
 
args = parser.parse_args()
print(args.accumulate(args.integers))

Toute ma démonstration s'appuie sur une manière de concevoir soit par des fichiers de configuration, soit par des arguments, comme on interagit avec un script à son lancement (je passe sur les échanges de données après).

Une fois que j'ai traité dans mon tutoriel les données fournies par sys.argv, j'ai le choix aussi de ne rien faire, de les utiliser (ou pas !) et d'avoir simplement un dictionnaire de données simple à utiliser, rapide et peut-être moins casse-gueule à mettre en œuvre et à débugger que argparse...

Last but not least, je fais la distinction entre ma classe Configuration et TTT, qui seule cette dernière "s'approprie" les arguments (traitement + doc). Ainsi si j'ai plusieurs serveur lancé sur des ports différents au travers du module multiprocessing, je peux avoir plusieurs docs, plusieurs traitements différents pour un même argument donné.

Bref mon tutoriel est orienté sur une création de contexte d'exécution.