satané xml

Spring, c'est pratique pour cabler et pour instancier; ça donne du coup envie de faire des bouchons en veux tu en voilà, d'instancier même des beans de démo de ton modèle métier...
Mais quand il faut stipuler les relations, les attributs, les class name, en XML !! la galère de saisie sans autocomplétion de code, sans vérificateur de référence, sans remaniement aisé...

On a le même symptôme que pour Hibernate ou Struts, pour tous ces "gros" frameworks à succès:

• qui dit framework puissant, dit souvent DSL puissant pour le programmer. Alors on choisit XML parce que c'est pratique à structurer, c'est générable... Mais surtout, pour le fabriquant du framework qui n'a pas tant de sous que ça pour se consacrer à autre chose que le coeur de son moteur, une technologie éprouvée, simple à parser !!
• puis quand le framework a réussi sa percée sur le marché sur le plan du coeur de son métier, vient le deuxième symptôme: un IDE. Se montent alors un projet, une équipe, pour réaliser un "éditeur" qui fera tout ce qui manque : autocomplétion, vérification de références, mais aussi affichage plus ou moins visuel, etc etc
• A chaque fois, ces projets peinent; normal, un IDE c'est compliqué et cher, et peut être pas tellement adapté au modèle "open source" : en général il faut plutôt du temps plein, un focus plus important peut être que pour un moteur lui même, qui peut être fabriqué plus itérativement ?

Bref, tout ceci me ramène à mon dada actuel : les gens veulent faire des DSL intégrés à leur langange de programmation principal, avec facilité de "wizarder" dessus. Sun, au boulot.

En attendant, je vais essayé THE initiative qui me motive pas mal en ce moment : JACN. Comment écrire un fichier XML pour Spring... en Java.

On en reparle.