Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait)
Bon, tu défends une techno que tu viens d’apprendre il y a deux semaines. Ce qui veut dire que pour l’instant, tu as découvert les avantages de la techno, mais que tu n’as pas encore suffisamment de recul pour t’être pris dans la tête les inconvénients.
Je pense que tes arguments vis à vis du cas de la migration xslt -> python sont pertinents, cela dit : s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.
En revanche, xslt a quand même pas mal de défauts, qui font que la plupart des projets que je connaisse qui ont décidé de se baser dessus se disent qu’ils auraient peut-être mieux fait de faire une moulinette en pour faire les opérations (je suis dans ce cas, j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça).
Parmi les défauts les plus souvent remontés :
- le manque d’opérations triviales (formatage de dates par exemple)
- la très mauvaise lisibilité --> il est difficile, en lisant une grosse feuille de style xlst, de comprendre ce qu’elle fait, dans quel ordre sont faits les traitements, etc.
Ces deux points sont un gros point noir :
- le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.
- le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».
Et il faut ajouter à ça :
- la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)
- les perfs désastreuses
Bref, personnellement, j’ai essayé, maintenant, j’évite autant que possible. À nombre de lignes égal, un programme est nettement plus lisible qu’une feuille xslt. Et xslt a tendance a être plus verbeux... :/
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nuances sur le nettoyage XSLT
Posté par whity . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 10.
Bon, tu défends une techno que tu viens d’apprendre il y a deux semaines. Ce qui veut dire que pour l’instant, tu as découvert les avantages de la techno, mais que tu n’as pas encore suffisamment de recul pour t’être pris dans la tête les inconvénients.
Je pense que tes arguments vis à vis du cas de la migration xslt -> python sont pertinents, cela dit : s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.
En revanche, xslt a quand même pas mal de défauts, qui font que la plupart des projets que je connaisse qui ont décidé de se baser dessus se disent qu’ils auraient peut-être mieux fait de faire une moulinette en pour faire les opérations (je suis dans ce cas, j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça).
Parmi les défauts les plus souvent remontés :
- le manque d’opérations triviales (formatage de dates par exemple)
- la très mauvaise lisibilité --> il est difficile, en lisant une grosse feuille de style xlst, de comprendre ce qu’elle fait, dans quel ordre sont faits les traitements, etc.
Ces deux points sont un gros point noir :
- le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.
- le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».
Et il faut ajouter à ça :
- la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)
- les perfs désastreuses
Bref, personnellement, j’ai essayé, maintenant, j’évite autant que possible. À nombre de lignes égal, un programme est nettement plus lisible qu’une feuille xslt. Et xslt a tendance a être plus verbeux... :/
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0