• Pourquoi une sauvegarde ailleurs, c'est mieux qu'un dépôt local? En équipe, ok, c'est indéniable. Si on veut diffuser ses sources, aussi. Sinon, pourquoi ne pas garder en local, avec un système de backup quelconque (type RAID Logiciel / Copie directe)? Le SVN se charge de rattraper les erreurs du développeur (mauvais feature par exemple), et le RAID se charge de sécuriser le stockage lui-même (pour éviter de tout perdre si un disque grille).
• En quoi XSL est-il "plus compliqué" qu'un autre moteur de template, non-W3C? Le processeur XSL est inclus par défau t dans PHP (pas de maintenance supplémentaire), et rien n'interdit d'encapsuler ce mécanisme XML/XSL dans un namespace PHP (il y a peut-etre des frameworks pour ça). Cela simpifie même le dev: pas de soucis d'XSS (DOMDocument l'en empêchera intrinsèquement, comme une requete préparée empêche l'injection), le code du template est hors du code PHP (il est même dans les codes accessibles depuis le web, dans /www/), et la maintenance est nulle (PHP inclue d'origine un processeur XSL, et la maintenance du processeur XSL du navigateur, si on l'utilise, n'est pas de notre ressort). Accessoirement, en cas de changement de code serveur (vers Node.js par exemple), les templates sont directement réutilisables (beaucoup de langages ont un processeur XSL inclus).
• Compiler le template en PHP, pourquoi pas, mais en XSL, tu peux laisser le navigateur se démerder tout seul pour l'appliquer
En revanche, bien d'accord pour le coté le temps d'apprentissage << le temps de dev from scratch + maintenance.
Pour le déploiement, j'ai croisé Rocketeer (PHP) il y a peu: quelqu'un l'a-t-il testé? Je n'en ai pas eu l'occasion...
• En quoi XSL est-il "plus compliqué" qu'un autre moteur de template, non-W3C? Le processeur XSL est inclus par défau t dans PHP (pas de maintenance supplémentaire), et rien n'interdit d'encapsuler ce mécanisme XML/XSL dans un namespace PHP (il y a peut-etre des frameworks pour ça). Cela simpifie même le dev: pas de soucis d'XSS (DOMDocument l'en empêchera intrinsèquement, comme une requete préparée empêche l'injection), le code du template est hors du code PHP (il est même dans les codes accessibles depuis le web, dans /www/), et la maintenance est nulle (PHP inclue d'origine un processeur XSL, et la maintenance du processeur XSL du navigateur, si on l'utilise, n'est pas de notre ressort). Accessoirement, en cas de changement de code serveur (vers Node.js par exemple), les templates sont directement réutilisables (beaucoup de langages ont un processeur XSL inclus).
• Compiler le template en PHP, pourquoi pas, mais en XSL, tu peux laisser le navigateur se démerder tout seul pour l'appliquer
En revanche, bien d'accord pour le coté le temps d'apprentissage << le temps de dev from scratch + maintenance.
Pour le déploiement, j'ai croisé Rocketeer (PHP) il y a peu: quelqu'un l'a-t-il testé? Je n'en ai pas eu l'occasion...