Moteur de template

[Prélude]

Si tu as du temps, ce n'est pas du temps perdu, loin de là.
C'est bien aussi de s'inspirer de l'existant, de mettre le nez dans le code et de voir comment ça fonctionne, pour ensuite adapter à ta sauce.
Mon framework a été réalisé sur plusieurs années. Le temps que j'y ai passé, c'est du temps qui était payé par des clients (et par moi) pour réalisé leur site (et les miens). Il en ressort un truc un peu bâtard, mais super rapide, léger et fonctionnel. Simple à prendre en main, à maintenir et à modifier.
Tout le monde n'a pas la chance d'avoir du temps à consacrer pour ça.
Si tu as cette chance, vas-y, sincèrement, n'écoute pas les Xenos et autres intégristes (joke).
Si tu manques de temps, consacres le plutôt à l'apprentissage d'un bon framework qui a fait ses preuves.
Mais si tu as du temps, je suis curieux de voir ton framework et les solutions mises en place

[Sephi-Chan]

J'ai oublié de préciser que je parle de développement dans un but de production, pas d'apprentissage.

Et même pour l'apprentissage, je pense qu'il vaut mieux tester chaque framework et en regarder les entrailles. Ce qu'on développe nous-même est souvent bien plus basique et moins réfléchi : on apprend mieux en regarder le travail de vrais experts. Donc selon moi, réinventer la roue pour la comprendre reste infiniment moins efficace qu'inspecter une multitudes de roues différentes. Et ça développe en plus la capacité d'adaptation, indispensable quand on développe. Si tu as vraiment du temps à consacrer au développement de ton propre framework au lieu de créer ton jeu (ce qui a l'air d'être ta volonté principale), je te conseille plutôt de faire ça : ce sera infiniment plus enrichissant.

Le fait est que je ne crois pas (je n'y crois plus serait plus exact) aux frameworks minimalistes : au final ils font tous la même chose. Ils ne sont minimalistes qu'au début (je préfère le terme incomplet, plus réaliste). Idem pour la légèreté : mais qu'est-ce que ça veut dire, objectivement, léger ? Et rapide ? Est-ce que vous avez vraiment mesuré les performances (avec des outils, pas au feeling) d'applications Symfony/Laravel/Rails/etc. et celles vos applications avec frameworks maison, sur le même matériel ? J'en doute. Je sais que certains ont comparé objectivement des frameworks industriels minimalistes (type Sinatra) avec des frameworks industriels full-stack (type Rails) et il en ressort que l'overhead des frameworks full-stack est souvent observés sur des tests basiques (le fameux hello world), mais que dans la vraie vie c'est négligeable, à plus forte raison quand les outils proposés par le framework full-stack lui permettent de prendre les devants (grâce aux outils de fragment caching intégrés, ou même de caches de requêtes, etc.). Et l'avantage, c'est que puisqu'ils sont soutenus par des communautés et distribués sous forme de package, on profitera très facilement du travail des dizaines de personnes qui contribuent à le rendre meilleur et plus performant.

Je ne dis pas que les solutions artisanales ne fonctionnent pas, je dis simplement que c'est loin d'être optimal : que ce soit en temps homme ou en temps machine.

Donc effectivement, quand des outils existent, que tu te donnes un peu de temps pour les essayer et qu'ils te plaisent : utilise-le. Ce que tu pourrais recréer différemment sera forcément moins bien, moins sûr, moins rapide (à développer, debug et exécuter), moins bien maintenu. Ceux qui apportent des idées novatrices sont toujours des équipes solidaires, sponsorisées par leur employeur, et qui fédèrent des communautés (si quelque arrive à me donner un contre-exemple, je tire mon chapeau).


Concernant les scripts de mise en production, avec compilation des JS/CSS, il y a 2 approches : soit compilé sur la machine locale et envoyé sur la machine (ça utilise généralement Rsync ou SCP, plutôt que du FTP, désolé Prélude ), soit exécuté sur la machine (qui dispose bien sûr de quelques outils installés). A nouveau, la mise en production gagne à être industrialisée. L'avantage c'est que ça ne suppose pas l'utilisation d'un framework. On peut utiliser Mina ou Capistrano sur des projets développés avec n'importe quel langage, et même s'ils n'utilisent pas du framework. C'est juste qu'ils proposent souvent des bonus qui fonctionnent bien avec les frameworks industriels, donc encore une occasion de gagner du temps.

Effectivement, si tu as du mal à imaginer comment déployer via un script, c'est peut-être que tu ne vois pas assez large : laisse-donc tomber ton framework perso et regarde ce qui se fait. Je t'assure que tu en auras pour ton temps !


@ Xenos : L'argumentaire me semble invalide : quand tu changes de techno côté serveur (déjà hyper improbable) en cours de projet, le portage des vues sera le cadet de tes soucis. Et je ne vois pas en quoi passer par une couche intermédiaire de XML peut être bénéfique plutôt que de rendre directement du HTML, du JSON, du XML (RSS/Atom), etc. Surtout quand les différents rendus exigent un traitement différents (tu n'auras pas les mêmes requêtes SQL si tu rends le flux RSS de tes articles, la liste de tes articles sur ton site Web ou une réponse d'API JSON).

[Xenos]

On (là, je ne sais honnêtement plus qui) conseillé de jeter au moins un oeil aux codes sources de frameworks éprouvés: c'est effectivement une excellente idée, et cela a été très instructif. Si tu aimes taper du code plus que sortir des projets (pas de mal à cela), je te conseille de suivre cette même directive: cela te permettra de voir la structure choisie par le framework, et cela t'apprendra beaucoup

Pour le coup des "p'tits jeunes", je te rejoins: avant d'utiliser un framework, il faut en maîtriser le langage de base. C'est pas une usine magique à code, c'est seulement un ensemble d'outils écrits dans un langage (à connaitre donc, avant d'utiliser ces outils).

Un outil de déploiement, au fond, fait automatiquement ce que tu te farcis manuellement: minimifier ce qu'il faut, l'optimiser au besoin, synchroniser les BDD, regarder ce que le FTP contient, mettre à jour/uploader/supprimer ce qu'il faut, archiver ce qui existe avant de le remplacer (pour permettre un rollback du déploiement), lancer un mail aux membres de l'équipe avec les changements qui ont eu lieu, poster une news avec ce même changelog,...
Toutes ces fonctions ne sont pas forcément là,de base (pas sûr que Rocketeer ajoute une news à un wordpress à chaque déploiement), mais tu peux intégrer ces fonctionnalités à ces outils: au lieu de faire tout l'outil de déploiement, tu ne fais que la commande que tu veux exécuter: le reste est du ressort de l'outil de deploy.
C'est très pédagogique pour la structure du projet (séparer clairement les tâches, chainer des outils qui font une et une seule chose, et qui le font bien,...)

Si le framework ne fait pas ce que tu attends, vérifie que tu l'utilises bien, qu'il est bien à jour, que ce n'est ni un bug ni une feature request, et au besoin, change de framework: cela ne te coutera pas si cher que cela, car ton code métier (celui spécifique au jeu) ne changera peu voire pas.


[Edit]: zut, j'avais pas vu la 3e page! Donc je dis en fait comme tout le monde:

Si t'aimes apprendre, lit les codes sources des frameworks, et bidouille-les un peu: t'apprendras 10x plus vite

Il est vrai que pour la légèreté, un framework répandu pourra être bien plus performant qu'une bidouille perso pour les raisons évoquées par Sephi, auxquelles j'ajouterai que le temps du développeur est plus précieux que celui de la machine: des pages 10% plus lentes valent mieux que 6 mois de dev sur le projet (point de vue industriel).

@Sephi: le but n'est pas d'avoir le même contrôleur (qui fait les requêtes SQL) qu'on soit en HTML, API ou RSS, mais de sortir la génération du HTML/JSON/RSS/autre du code-serveur (PHP, Ruby, etc). Le contrôleur du site se contente de cracher du DOMDocument (XML) au lieu de cracher parfois du JSON, parfois du XML, parfois du HTML... On sort la vue du code PHP pour la mettre dans le XSL, tout comme on sort le Model pour le mettre dans un SGBD.
Mais bon, c'est peut-être qu'une question de points de vue... Utiliser XSL me semble plus intéressant qu'un paquet de code PHP pour les templates, d'autant que le XSL sera processé par un code C++ et non par des lib PHP, plus lentes.

[Ter Rowan]

perso ça m'intéresse toujours de voir ce que font les gens sur ce type d'activité, mais, le plus intéressantpour moi dans cette histoire, sera plus la critique des autres qui regarderont le code et diront, par l'expérience acquise avec d'autres FW ou leurs propres essais ce qui va bien, et surtout ce qui n'est pas bien

XML/XSL, c'est pas compliqué: y'a pas de langage à apprend (XSL et xHTML, c'est du XML)

Alors là c'est un argumentaire tout pourri Xenos

Je connais le XML et donc, je connais le mot clef / le système pour faire une boucle ? une condition ? l'affichage d'une variable ?

le XML est une grammaire, pas un langage

sujet verbe complément : en anglais comme en français, pas pour autant que je manie molière comme shakespire...

[Xenos]

D'accord, j'aurai du être plus précis et dire que pour XML, il n'a a pas grand chose à apprendre pour qui connait xHTML, et pour XSL, ce n'est pas plus complexe de l'apprendre que n'importe quel autre moteur de template.
Au lieu d'apprendre une grammaire et un vocabulaire, on n'a plus que le vocabulaire (les noms des balises) à apprendre. Le seul point délicat étant plutôt l'aspect déclaratif du langage auquel il faut se faire (on retrouve le même aspect dans HTML... mais vu les tartines de javascript parfois rajoutées par dessus, l'esprit déclaratif/fonctionnel est peut-être moins répandu que l'impératif).

(J'objecterai à la volée que si tu connais le Français, apprendre l'anglais ou l'espagnol est aisé, mais apprendre le japonais, le russe ou le chinois sera plus difficile !)

[niahoo]

Xenos je veux bien un exemple de template avec XSL pour générer une todolist ou une liste de post de blog (ou autre cas d'école)

[Xenos]

Je n'ai pas de todo-list d'exemple, mais W3Schools présente un exemple XSL pour afficher une collection de CD. Le XML de gauche sortirait alors du code serveur (pas forcément sous la forme d'une chaine de caractère: pour PHP, ce serait juste une variable contenant un DOMDocument) et le XSL de droite est le template à appliquer (note qu'il existe des <xsl:import> pour réutiliser des morceaux de templates dans d'autres).

Comme site qui utiliserait ce système, c'est difficile à dire car si le XML/XSL est processé coté serveur (comme les autres langages de templates le sont), alors le client ne verra aucune différence. Néanmoins, je pense qu'OVH utilise ce système, au vu de l'URI de la page d'accueil: www.ovh.com/fr/index.xml. Je ne serai pas étonné que le XSL soit appliqué coté serveur, pour servir du contenu HTML.

[niahoo]

Ok merci !

[Max72]

J'ai bien pris note de toutes vos remarques qui, comme d'habitude, poussent à partir sur des grosses librairies bien rodées plutôt que de créer une réponse propre à son besoin.

Sinon, vous connaissez absolument tous les mécanismes des librairies que vous utilisez ?

Je ferai un petit tuto sur la création de moteur de templates en PHP à titre informatif.

[niahoo]

Perso j'ai pour habitude de lire le code des librairies que j'utilise, rajouter du debug ou changer des trucs. ça permet de comprendre comment ça fonctionne. Ensuite, "absolument tous les mécanismes" non, bien sûr, mais comme d'habitude ce genre d'argument n'est pas valide. Par-ce que sinon, non seulement il va te falloir implémenter un moteur de template, mais également un langage pour le faire tourner, un OS pour installer le langage, voir même construire ton propre PC à partir de billes de métal et de plastique.

Sans ça, tu ne peux pas vraiment comprendre absolument tout ce qu'il se passe quand tu affiches ta page, même si tu as écrit le moteur de templates.

Edit : et de toute façon, je ne réfléchis pas comme toi. Je regarde mon besoin : générer du HTML avec des zones dynamiques dedans. Est-ce qu'il y a une librairie qui fait ça ? Oui ? Ok, vendu, pas besoin de "créer une réponse à son besoin" puisqu'elle existe déjà.

Bien sûr, quand on dit ça, et on l'a précisé, on parle de construire des systèmes destinés à la production. Sinon en termes d'apprentissage j'ai déjà écrit un framework MVC, un moteur de template, un ORM dans un langage fonctionnel, ce genre de trucs oui, c'est instructif, mais ça ne part pas en prod car ça demande trop de travail pour être maintenu, si toutefois ça fonctionne sans trop de bugs.

Et si un jour, j'ai un jeu en prod qui est très ralenti à cause du moteur de templates, alors ça vaudra le coup d'en écrire un plus léger. Car là le besoin aura changé, le besoin sera "avoir un moteur de templates plus rapide que celui que l'on utilise actuellement". Mais ça m'étonnerait qu'on en arrive là.

Ah et un dernier truc, qu'entends-tu par "grosses librairies" ? Est-ce que tu parles du nombre de lignes de code ?