• [^] # Re: Nuances sur le nettoyage XSLT

    Posté par . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 4.

    s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.

    Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.

    j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça

    Ouch, ça fait mal, oui.

    • le manque d’opérations triviales (formatage de dates par exemple)

    Bon, ça c'est vrai que ça semble un petit peu limité, et que je n'ai pas rencontré ce besoin encore, mais que ça serait handicapant.

    • 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.

    Mmmhh... dans les exemples que j'ai vu, je ne vois pas en quoi un code procédural serait plus lisible.

    • le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.

    Ça c'est clair que ça doit être rédhibitoire quand tu en as besoin.

    • le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».

    Encore une fois, je ne vois pas trop la différence. À moins que ça soit pour quelqu'un qui connaît mal XSLT, mais la critique peut alors valoir pour n'importe quel langage.

    • la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)

    J'ai effectivement un petit peu vécu ça, xsltproc que j'utilise pourrait être plus explicite sur certaines erreurs (comme quand tu appelles une template qui n'existe pas quand tu t'es trompé dans le nom).

    • les perfs désastreuses

    J'avoue ne pas avoir eu de problème avec ça, vu que mes fichiers sont de taille raisonnable.

    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... :/

    Oui, la verbosité n'aide vraiment pas. Mais ce qui me plaît vraiment et qu'on ne retrouve pas ailleurs, c'est la logique de parsing du langage : c'est hyper-bien adapté à du parcours d'arbre, et le matching est super pratique pour spécialiser certains cas. Ce genre de chose serait horrible à faire avec un autre langage. Tout ça se rapproche du fonctionnel, qui n'est pas facile à comprendre quand on est pas habitué, mais une fois que tu l'as saisi, ça simplifie tellement de choses...

    En fait, il faudrait juste une version moins verbeuse. J'ai pensé à du YAML pour décrire les XSLT, je ne sais pas si ça pourrait le faire.

    Merci pour ces remarques en tous cas, assez justes.