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 !

Que pensez-vous du langage XML ? Pensez-vous qu'il faille à présent passer à autre chose ?

Le , par grunt2000

4PARTAGES

0  0 
Bonjour,

Ca y est. Au plaisir d'ouvrir un livre Java récent et de découvrir qu'un mot-clé supplémentaire (pour les pratiquants, une annotation) dans mon code source saura remplacer un fichier XML dont la présence était auparavant obligatoire, je me dis que nous sortons peut être d'une période où tout n'était qu'XML. Jusqu'à l'indigestion.

Il y en eu partout et pour tout. Si pour l'échange de données entre systèmes il avait des atouts certains, je défends la thèse qu'il a été utilisé abusivement. Le paramétrage des composants, par exemple, est trop souvent passé par lui.

Et cela a mené à des situations extrêmes. Il devenait parfois plus délicat de réussir son XML de paramétrage ou de compilation que le propre code source que l'on voulait faire fonctionner. Java J2EE - mais est-il le seul? - nous a pendant des lustres gratifiés de mille fichiers XML à produire pour tout et n'importe quoi. Une source de gêne certaine.

Maven 2, qui sert à la construction de projets et qu'il est de bon ton de trouver merveilleux (alors je vais essayer de l'écrire aussi: "C'est bien ma veine!", a atteint à mes yeux des sommets de farfeluterie et d'obscurité dans ses fichiers pom.xml, décrivant les travaux qu'il avait à mener.

Et aujourd'hui vient (ou revient) le paramétrage par script, fondé sur un langage dédié à l'application que l'on veut paramétrer. Je pense que c'est la bonne solution.
Il assurera une meilleure clarté et une évolution plus facile si ces langages se fondent sur des grammaires claires.

Mais il est tard. Je pense que bien qu'XML ait eu beaucoup d'atouts, il a été utilisé souvent d'une manière qui a généré de la complexité. Qu'il est un révolutionaire des années 2000 dont on a le droit de tirer un bilan, d'utiliser "notre droit d'inventaire", comme on dit.

Qu'en pensez-vous?

Grunt.

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

Avatar de Killing Joke
Membre actif https://www.developpez.com
Le 31/03/2010 à 0:12
Je partage complètement cet avis !

Le XML est devenu une plaie aujourd'hui (d'ailleurs on parle souvent de XM-Hell !), parce que, en effet, utilisé totalement abusivement, Spring en tête (il y a de bons concepts dans Spring mais beaucoup de mauvaises choses aussi) suivi de près par Maven qui est une des plus grosses fumisteries de ces dernières années (oui les POM.xml sont illisibles, mais en plus, on nous avait vendu une solution où il y aurait moins de répétitions à faire que dans des build.xml ANT, résultat, entre chaque projet Maven on passe quand même notre temps à copier/coller/paramétrer des blocs de config de plugins et de reports ...).

L'autre point qui m'agace au plus haut point c'est le chargement de configuration "auto-magic" avec un fichier pris dans le classpath (dans un jar, dans web/WEB-INF/classes, etc.), c'est insupportable comme mode de fonctionnement (heureusement que ce n'est pas utilisé par tout le monde), on ne sait jamais qu'est ce qui est pris en compte et activé : marre de tout ce bordel de configuration. Il serait temps que tout le monde revienne à un principe simple : faire simple !
1  0 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 12/03/2010 à 12:15
Salut

Je suis complètement d'accord avec toi. Le XML est une plaie !! Il parait que c'est human readable/writeable mais, la réalité est autre. Autant, il est pratique pour échanger des données entre deux programmes (indépendant de la plate forme utilisé et des librairies dispo pour n'importe quelle plate forme), autant il est monstrueux quand on doit aller taper dedans à la mano.

Allez, en vrac:
  • struts
  • spring
  • web.xml (JEE)
  • hibernate
  • etc.


Et, c'est vrai, il est terriblement simple de faire une erreur dans un fichier XML. Je me rappellerai toujours de cette virgule manquante dans un fichier de conf struts qui me donnait une jolie page blanche (plus qu'à modifier le fichier et relancer le serveur).

Les annotations nous permettent de mettre les meta informations directement dans le fichier source. Je ne sais pas si c'est un plus mais, c'est bien plus clair que cet amas de < et > et &quot;

Pour info, avant l'arrivée des annotations il y avait la possibilité d'utiliser XDoclet http://xdoclet.sourceforge.net/xdoclet/index.html

J'ai toujours penser qu'un fichier XML ne doit pas être saisie à la main mais :
  • être généré
  • offrir une interface graphique permettant de visualiser/éditer le fichier xml


Yann
0  0 
Avatar de Hephaistos007
Expert confirmé https://www.developpez.com
Le 15/03/2010 à 21:45
En même temps, il faut bien des fichiers de configurations. Plusieurs solutions s'offrent à nous :
  • un fichier à base de texte (dans la même veine que Property en Java)
  • un dialecte XML
  • un langage de scripting dédié


La solution 1 a été abandonnée pour sa faible structuration. Le solution 2 est un consensus entre 1 et 3. La solution 3 est logiquement la meilleure mais encore faut-il que les éditeur développent l'outillage qui va avec. Le coup des annotations, je suis à 100% pour, mais cela ne peut probablement pas être aussi expressif que les solutions 1,2 et 3.
0  0 
Avatar de lollancf37
Membre du Club https://www.developpez.com
Le 16/03/2010 à 10:04
Citation Envoyé par Hephaistos007 Voir le message
En même temps, il faut bien des fichiers de configurations. Plusieurs solutions s'offrent à nous :
  • un fichier à base de texte (dans la même veine que Property en Java)
  • un dialecte XML
  • un langage de scripting dédié


La solution 1 a été abandonnée pour sa faible structuration. Le solution 2 est un consensus entre 1 et 3. La solution 3 est logiquement la meilleure mais encore faut-il que les éditeur développent l'outillage qui va avec. Le coup des annotations, je suis à 100% pour, mais cela ne peut probablement pas être aussi expressif que les solutions 1,2 et 3.
La solution 1 n'a pas été abondonnée, c'est vrai que c'est peu pratique sur les projets conséquents mais de la a dire que sa faible structuration rend cette solution inéficace c'est un peu abusé. C'est simplement qu'il est plus facile de gerer des métadonné avec XML qu'avec un simple fichier texte et que de plus en plus on travail avec des métadonnées.

En ce qui concerne la solution 3 (un language de script dédié), si les éditeurs utilisait des languages script déja existant et batissait des structure de configuration solide, je pense que cela serait beaucoup mieux.

Je ne pense pas aussi que XML est un consensus entre les deux. La solution script offre beaucoup plus de possibilité que le XML, a mon avis, les deux ne sont pas comparable meme si l'on peut utilisé XML pour de la configuration.

Il y a aussi la solution de parametrage via BDD, je pense ici a une base de données de type SQLite meme si je prefere que ma conf. soit mise dans de bon vieux fichier texte.

Pour ma part je suis d'accord avec yann2 quand il dit que le XML devrait etre généré et pas ecrit a la main. Le XML c'est quelque chose d'excellent pour la transmission de données ou la description de données de maniere général cependant des que l'on y ajoute le facteur humain c'est tout de suite moins attirant et ce pour pleins de raisons (protocole obscure, redondances, dépendances obscure ...).
0  0 
Avatar de icareo
Membre habitué https://www.developpez.com
Le 24/03/2010 à 8:16
Tout à fait d'accord avec toi.
Je lisais justement un article intéressant l'autre jour qui m'a fait réaliser (ou presque) l'abus :

It's all so easy. So easy, indeed. So easy to burn megabytes of RAM parsing XML infosets just to pull a few elements out of them.
(tiré de Writing Faster Managed Code: Know What Things Cost )

... c'est vrai qu'on a un peu tendance à oublier ce que représentent les quantités de RAM occupées (vite monstrueuses pour des petites applis managées) en comparaison avec les standards d'autrefois. (que je n'ai pas connu, soit dit en passant !)

Je m'applique depuis à employer plus souvent la "solution 1 ou 3" (suivant complexité des objets à stocker)
0  0 
Avatar de davcha
Membre expérimenté https://www.developpez.com
Le 25/03/2010 à 23:53
Json.
0  0 
Avatar de icareo
Membre habitué https://www.developpez.com
Le 28/03/2010 à 3:18
+1 pour json.
plus lisible.
plus léger.
0  0 
Avatar de Tommy31
Membre chevronné https://www.developpez.com
Le 28/03/2010 à 10:51
Il y a d'autres alternatives : yaml un langage textuel très orienté lisibilité, ou les protocols buffer de google par exemple.
0  0 
Avatar de kassak
Futur Membre du Club https://www.developpez.com
Le 30/03/2010 à 22:18
YAML est un très bon format.
JSON est très efficace aussi.

C'est sûr que XML c'est lourd, très lourd...
0  0 
Avatar de Jérémie A.
Membre averti https://www.developpez.com
Le 30/03/2010 à 23:23
Citation Envoyé par Tommy31 Voir le message
Il y a d'autres alternatives : yaml un langage textuel très orienté lisibilité
Je trouve le YAML parfaitement imbuvable à côté de l'XML. Ce truc est une vraie horreur, et n'est clairement pas si lisible que ca. A force de vouloir simplifier les structures, on en perd justement en lisibilité. Bref, perso, XML ne me dérange pas du tout.
0  0