Moteur de template

[Xenos]

Le code XML, peu importe sa source: tapé à la main, généré à partir du MySQL, généré à partir du PHP, ou encore abstrait dans un objet PHP (un DOMDocument PHP qui représente un document XML et qui contient les données dudit XML: il n'est pas sauvé sur le disque, c'est juste un objet PHP, dans une variable). C'est l'intérêt de toute interface (décorrélé d'où ca vient de ce que c'est/où ça va).

Le code XSL, c'est le template, qui là encore vient d'où on veut: tapé à la main (le plus probable), généré par un script quelconque et sauvé sur le disque, ou encore généré à la volée (là encore, via un objet DOMDocument par exemple).


• Cela simplifie les vues car tu n'as pas de moteur de template à créer: ce moteur existe déjà, et s'appelle XSLTProcessor (pour PHP).
Tout ce que tu crées, c'est le template lui-même (le document XSL) et les données à y mettre (le document XML contenant les données).

Au fond, au lieu de tapper <% machin %> et de reposer sur une lib tierce (la tienne, ou une lib de moteur de template existante), tu te reposes sur une lib intégrée à PHP (ou autre langage), et tu tapes <xsl:value-of select="//values/machin">. L'atout étant alors la portabilité puisque XSLT existe sur de nombreux langages.

Disons qu'en un sens, je souligne juste qu'il existe un moteur de template standard (XSL) qui peut être utilisé de manière très simple quoi qu'on en dise iffle: En ce sens, c'est un peu à coté du sujet, désolé !

Pour ma part, j'aime ce système car le DOMDocument XML intermédiaire peut avoir deux destinations:
→ Ou bien il reste dans une variable PHP, et le serveur applique la transformation XSL pour envoyer le résultat HTML au client
→ Ou bien le XML est directement envoyé au client si celui-ci est compatible, et le client (le navigateur par exemple) se charge de la transformation.

Cela allège énormément la bande passante (ou bien on transfert le HTML classique, ou bien on transfère uniquement le XML contenant les données, qui est plus léger), cela permet de faire l'API et le site en même temps (si on veut l'API, il suffit de demander le XML qui existe déjà), le tout en n'utilisant qu'un seul code (le même XSL sera utilisé par le serveur ou le client) qui permet d'ailleurs de générer les sorties que l'on veut (laisser filer le XML, le transformer en HTML, en JSON,...). En plus, cela détache la vue du reste du code PHP: c'est une belle application du MVC (M: MySQL/XML, V: XSL, C: PHP).

[Prélude]

Heureusement que les concepteurs de frameworks récents ne se sont pas dit "oh bah, ça existe déjà..."
J'ai moi même fait mon framework pour mes jeux et ça m'intéresse de voir d'autres solutions histoire de compléter mes connaissances

[Max72]

Xenos : Je ne dis pas que ce n'est pas bien, mais selon moi ça alourdit encore la mise en place des vues. Peut-être à tort, je te l'accorde.

En fait, par dessus ça, c'est que j'en ai marre des soi-disant standards.
Lorsque je me suis mis au PHP, il a fallu apprendre ensuite la POO. Puis le MVC, et les frameworks (tout le monde un tant soit peu censé s'était déjà créé son propre framework, mais c'est pas pareil. Ah.. ^^ ).
Je passe sur les nouveautés des autres langages (HTML5, CSS3, ..), ça c'est bien
Puis maintenant il faut coder en respectant les PSR (non mais pour qui ils se prennent ceux-là ? ), sinon ton projet n'est pas viable.
Idem si tu n'as pas de dépôt sur GitHub, tu es un arriéré.
Tu veux installer un petit ORM ? Installe d'abord Composer sur ton pc, sinon tu ne l'auras jamais.

Et maintenant, tu connais l'HTML ? Oui ? Tiens alors, voilà de quoi occuper tes journées. On code ses vues en XML maintenant..

Je ne dis pas que toutes ses choses ne sont pas bien, mais je trouve qu'il faut de plus en plus de temps pour rester à la page.
Quand est-ce que je trouve le temps de coder mon jeu moi ? ^^

Heureusement que les concepteurs de frameworks récents ne se sont pas dit "oh bah, ça existe déjà..."
J'ai moi même fait mon framework pour mes jeux et ça m'intéresse de voir d'autres solutions histoire de compléter mes connaissances

J''ai eu la même réflexion

[Xenos]

Je me répète peut-être un peu, mais si tu connais HTML, tu connais certainement xHTML (le "HTML propre où on ferme ses balises"), et donc, tu connais déjà le XML. HTML, c'est simplement un Framework de XML.

• L'intérêt de l'informatique, c'est la combinatoire. T'as le droit d'envoyer promener les standards. Tu te fais ta petite bulle dans ton coin, avec ta popote dedans, et le reste du monde osef. Pas de soucis, mais dans ce cas, le reste du monde s'osef de ta bulle

Coder sur un standard permet d'être inter-opérable avec d'autres éléments.

• Après, les outils faits par les autres sont autant de temps que tu ne dépenseras pas à les faire. Entre chercher 30 minutes sur le net pour comparer 3 logiciels open-source, et passer 2 semaines à coder un truc dans ton coin qui ne sera pas inter-opérable avec ce qui existe, à toi de voir ce qui te plait le plus entre rentabiliser ton temps et taper du code.
J'ai déjà eu ce débat avec quelqu'un ces derniers temps... :p

• Pour ce qui est des PSR, ce sont seulement des habitudes de codage, qualifiées de "bonnes". T'as le droit de les envoyer promener. T'as le droit de te fixer tes règles de codage (ou de fixer la règle: "y'a pas de règle"). Mais les PSR sont sorties des expériences des milliers d'autres dev de la planète, donc elles ont peut-être un fondement d'utile et de vrai

• Pour les dépôts GitHub, j'ai jamais entendu que si à 50 ans t'as pas un dépôt GitHub, t'as raté ton dev. Avoir un logiciel de gestion de version, cela facilite la vie (même en dev seul, bien que l'impact soit moindre). Personne ne t'oblige à mettre ce dépôt en ligne, encore moins sur GitHub. C'est, là encore, une question d'inter-opérabilité: un dépôt GitHub, beaucoup de gens sauront y accéder et le clôner: si tu fais de l'open-source, c'est une très bonne idée. Si tu fais du dev privé, questananafout'?!

• Sur l'argument du XML/XSL alourdit, là, j'ai rien à y opposer... Mais cela alourdi au même titre que coder en OO est plus lent que coder en procédural... Niveau temps d'exécution, c'est plus lourd, mais coté développeur, c'est plus simple car on gère un domaine bien carré et délimité, sans s'éparpiller dans le reste du code.

• Les nouveautés HTML5/CSS3 sont bien? Alors considère les nouveaux outils (composer, phpUnit,...), les nouveaux langages (XSL, Ruby,...) et les nouveaux standards (PSR) comme d'autres formes de progrès

(Désolé des réponses peut-être sèches parfois, mais j'ai bouffé du jqGrid ces derniers jours... une horreur de code vomissant sur les standards et mélangeant allègrement le fond, la forme, le style en faisant passer le tout pour une révolution)

[Sephi-Chan]

Je ne vois pas l'intérêt d'ajouter des couches de traitement là où ce n'est pas utile. Tu peux produire du HTML ou du JSON (selon ce que le client demande) depuis ton code plutôt que du XML qui sera transformé en HTML ou en JSON. Un XML commun ne me semble pas pertinent dans la mesure où on n'attend pas les mêmes informations d'une API (ou d'un appel Ajax) ou d'une page Web : les traitements effectués par le serveur (requêtes SQL, etc.) divergeront forcément à un moment ou un autre.

@ Max : ça représente du boulot de se mettre a niveau parce que tu n'as pas appris dans de bonnes conditions ; Simplement parce que ces bonnes conditions n'existaient pas quand tu (c'est un tu de généralité) as appris PHP "from scratch" : il n'y avait pas ou peu de frameworks, pas de design pattern, un modèle objet balbutiant (PHP 4 c'est déjà le moyen âge), bref : c'était un milieu amateur.

Maintenant la technologie PHP s'industrialise et c'est très bien (moi je m'en fous j'ai changé de crèmerie, mais je sais quand même que c'est une bonne chose). Ca permet d'utiliser facilement des libs écrites par d'autres sans galèrer a les intégrer dans son projet (pour charger les bons fichiers), ni à les installer en dezipant une archive (bonjour la corvée de mettre à jour les versions, vive le gestionnaire de paquet et l'écriture d'une liste des dépendances qui permet de voir d'un coup d'œil ce qu'on utilise).

Tu crois que Composer alourdit ton processus de developpement mais tu te trompes. Il l'accélére considérablement. Pas besoin de te connecter à un quelconque site, puis télécharger, puis desarchiver pour mettre à jour une dépendance (ou même pour savoir que tu n'es plus a jour), une petite ligne de commande suffit.

Idem pour les frameworks, tu crois gagner du temps a t'en faire un minimaliste (pour t'economiser un temps d'apprentissage ? Mais tu le perds 100 fois en redéveloppant-en-moins-bien) mais tu te trompes probablement. Quand une des fonctionnalités de ton framework (qui aura été copié/collé d'une app a l'autre) présentera des défauts (bugs, failles, etc.) tu devras maintenir chaque app séparément. Toutes les fonctionnalités recurrentes d'une app sont les mêmes pour beaucoup (quels que soient tes besoins, d'autres ont eu les mêmes), et de très bons développeurs ont déjà repondu au besoin avec une bonne vision d'ensemble.

Même de vieilles technologies comme Java on parfois un apport de sang neuf (avec des frameworks comme Play!) : ils sont soutenus par des petits groupes (des collègues d'une société, souvent) qui deviennent des communautés actives. Les initiatives individuelles (qui ont vocation à le rester) sont inutiles, inefficaces.


Une fois le retard rattrapé dans la techno, il suffit de 10 minutes de veille par semaine (ou plus si on est curieux) pour se tenir à jour.


Quant à GitHub (ou une alternative self-hosted) et le versionnement, c'est très utile pour ne pas perdre ton travail (avoir un dépôt local c'est bien, une sauvegarde ailleurs c'est mieux) et pour lui créer un historique. C'est également génial pour pouvoir faire du réfactoring sans crainte (on peut revenir en arrière), pour trouver quand a été introduit un bug (via git bisect) ou déployer du code (ceux qui font du drag and drop dans un client FTP ne sont pas sérieux).

Ah oui : le développement local est une chose, la mise en production une autre. Comment vas-tu synchroniser le schéma de tes based de données locale et de production (et les transformation de leur contenu parfois) ? Les frameworks proposent un système appelé migrations pour ça. Comment vas-tu proposer des CSS et Javascript compactés en un fichier et minifiés (tout en les ayant normaux et lisibles quand tu développes et debug) ? Les frameworks répondent a ça aussi, avec expiration automatique des caches chez les utilisateurs. Et j'ai plein d'autres exemples. 

[niahoo]

mais plus mille ... moi aussi j'ai fait mon propre framework, et c'était fun. maintenant je finis des projets et ça l'est encore plus. Surtout pour la maintenance.

Et juste un truc, twig (et blade) ça « compile » ton template vers du PHP, et ça le met en cache. C'est extrêmement rapide.

[Aedius]

Je suis globalement d'accord avec tout ça.

Après faire son propre framework, son propre moteur de template, ça permet aussi de comprendre comment marche les autres et de mieux saisir les enjeux des choix fait par les autres solutions.

Dans un jeu des fonctionnalitées qu'on retrouve très souvent et qu'on pourrait voir "built-in" serait un système d'info-bulle, de sélection par drag and drop, un système anti-bot.

J'entends par système anti-bot par exemple un template dont les noms des class et id pour le css changerait très régulièrement ( j'avais déjà vu ça sur un jeu ) et même l'ordre des données dans le html pourrait être changé d'une fois sur l'autre et rétabli en css
( j'ai déjà vu ce genre de chose sur un jeu web ou le créateur faisait tout pour que les bots ne puissent plus marcher, mais au final ça n'avait que ramené des gens interressé par le challenge de combattre son système )

[Prélude]

ceux qui font du drag and drop dans un client FTP ne sont pas sérieux

Quoi ? Quoi ? Je ne serais pas sérieux ?!

Non, sérieux, si vous avez le temps, faites votre propre framework et revenez après à des produits bien foutue et maintenu par une communauté. Mais apprendre est encore mieux que d'utiliser sans comprendre.
Enfin, c'est juste pour un apport personnel de connaissances.

[Xenos]

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

[Max72]

Ce qui en ressort de tout ça, c'est que si un outil existe, alors il faut selon vous absolument l'utiliser et ne pas chercher à le recréer différemment.

C'est sûrement l'expérience qui parle. De mon coté, je me dis qu'il n'y a probablement pas que moi qui cherche un truc simple et sans fioriture. M'enfin.

Je sais pertinemment que je perds du temps à recréer tout ça, mais je vois ça dans un but pédagogique. Apprendre, j'adore ça. Et puis si au final j'arrive à un truc qui fonctionne, j'aurai perdu du temps, c'est tout, j'aurai peut-être gagné en conception ou autre.

Savoir utiliser sans comprendre : Via Skype, j'ai déjà discuté avec des mecs (des jeunes principalement) qui ont appris le PHP avec un framework. Résultat, dès qu'il faut bosser en dur, c'est la routasse complet. Par exemple, un mec qui sait utiliser Laravel mais qui me sort un code comme ça (cas réel) :

Code PHP :

<?php 

...

$var = array();

$var = "erreur";

...