En fait le problème que j’avais eu à l’époque avec Xslt, c’est que le découpage fonctionnel est beaucoup moins évident à voir et à faire que dans un langage impératif. Or, le découpage fonctionnel, c’est un des critères principaux de lisibilité.
C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.
L’autre gros soucis, c’est qu’il est facile d’avoir des effets de bord globaux sans le faire exprès --> ça, c’est terrible pour la maintenance. À chaque modification de la feuille, tu pries (et en plus, on n’avait pas TUs corrects derrière).
Mmhh... je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.
En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.
On retrouve le même genre de choses chez prolog, erlang (je crois), ou dans une certaine mesure les templates c++.
Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives... je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres... bon, je les connais moins aussi).
C’est très pratique pour certaines choses, très puissant, mais quand on en abuse, c’est facile d’arriver à des choses totalement illisibles.
Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de "Domain Specific Language" pour le traitement d'arbres.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 3.
C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.
Mmhh... je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.
En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.
Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives... je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres... bon, je les connais moins aussi).
Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de "Domain Specific Language" pour le traitement d'arbres.