Pourquoi les moteurs de templates ?
1- pour fournir une syntaxe "gentille" pour les non-codeurs
2- pour faciliter la maintenance des vues parce que la syntaxe est "gentille"
3- pour automatiser les mises en cache des vues (tout passe par le moteur de templates qui gère)
4- parce que ça va augmenter la productivité
Bien, ce sont les arguments que j'ai déjà entendu sur le sujet. Il se trouve que je travaille dans le développement d'applications "oueb" (et même "oueb deupouainzéro" il y a peu) depuis plusieurs années, et que j'ai testé différentes approches concernant les vues. Et la seule qui marche vraiment bien, c'est le pattern MVC + la factorisation dans des méthodes du code de vue redondant + des conventions claires et connues de tous les codeurs + du simple code du langage utilisé dans les vues, tout simplement. Oh, j'oubliais : bien choisir son langage. Un exemple de framework qui présente tous ces aspects : Ruby on Rails. Oups, ce n'est pas du PHP ? Justement, j'y reviens plus tard.
Mais alors, pourquoi les bons arguments pour les templates ça marche pas ?
Eh bien :
1- a. Si la syntaxe à besoin de devenir "gentille" c'est qu'elle ne l'était pas à la base. Exemple : PHP, plombé par des scories de C, trop fait pour "coller au web" mais pas assez pour factoriser correctement le code, pas assez accessible pour un profane du développement
1- b. La syntaxe ne sera jamais "gentille" pour le non-codeur, au plus elle sera un tout petit peu moins aggressive, au pire elle fera plus peur. Regardons les choses en face, pour faire du code, il faut apprendre des langages de code, quel intérêt dès lors de forcer des développeurs à apprendre un para-langage super-spécifique ?
1-c. Les non-codeurs, par essence, ne devraient pas avoir à coder. Pour coder, et même pour faire de l'intégration, embauchez des codeurs, ils feront du travail plus propre. Les designers, ils font le design, au mieux ils découpent des éléments pour les codeurs, et ça suffit déjà à les occuper s'ils sont compétents.
1-d. La coloration syntaxique, il faut qu'elle soit adaptée à la nouvelle syntaxe. Ou alors faut coder en daltonien.
2-a. Ca ne facilite pas la maintenance de forcer les mainteneurs à connaître un langage en plus. En fait ça le complique.
2-b. Le moteur de template va évoluer. Faut-il répercuter les évolutions ? Ca coûte du temps inutile tout ça, ça apporte des risques d'effets de bord, et ça rapporte généralement rien de concret. Sauf quand ça corrige des bugs. Donc on le fait quand même ?
2-c. De même que pour développer des vues c'est mieux d'avoir un développeur, pour les maintenir ça peut même être critique. Les vues évolues en se compliquant quand on les laisse suivre leur nature, il faut un bon jardinier pour élaguer les branches mortes sans couper les branches importantes et faire un beau jardin.
3- On peut très bien automatiser les mises en cache sans besoin de moteur de template. Il suffit de faire des conventions claires et de définir un point de passage obligé pour le traitement des vues.
4-a. Au final, au mieux ça va faire baisser la productivité le temps que les développeurs acquièrent l'outil, au pire ça va la plomber durablement parce que les développeurs ne prennent pas le temps d'apprendre les petites subtilités qui permettraient de gagner du temps.
4-b. Et surtout, en utilisant un bon langage et en factorisant on obtient les mêmes effets positifs sur la productivité.
Bref, le moteur de template c'est un peu un pansement sur la béquille d'une personne qui a deux jambes bien portantes.
# Des syntaxes spécialisées.
Posté par Bastes . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 6.
1- pour fournir une syntaxe "gentille" pour les non-codeurs
2- pour faciliter la maintenance des vues parce que la syntaxe est "gentille"
3- pour automatiser les mises en cache des vues (tout passe par le moteur de templates qui gère)
4- parce que ça va augmenter la productivité
Bien, ce sont les arguments que j'ai déjà entendu sur le sujet. Il se trouve que je travaille dans le développement d'applications "oueb" (et même "oueb deupouainzéro" il y a peu) depuis plusieurs années, et que j'ai testé différentes approches concernant les vues. Et la seule qui marche vraiment bien, c'est le pattern MVC + la factorisation dans des méthodes du code de vue redondant + des conventions claires et connues de tous les codeurs + du simple code du langage utilisé dans les vues, tout simplement. Oh, j'oubliais : bien choisir son langage. Un exemple de framework qui présente tous ces aspects : Ruby on Rails. Oups, ce n'est pas du PHP ? Justement, j'y reviens plus tard.
Mais alors, pourquoi les bons arguments pour les templates ça marche pas ?
Eh bien :
1- a. Si la syntaxe à besoin de devenir "gentille" c'est qu'elle ne l'était pas à la base. Exemple : PHP, plombé par des scories de C, trop fait pour "coller au web" mais pas assez pour factoriser correctement le code, pas assez accessible pour un profane du développement
1- b. La syntaxe ne sera jamais "gentille" pour le non-codeur, au plus elle sera un tout petit peu moins aggressive, au pire elle fera plus peur. Regardons les choses en face, pour faire du code, il faut apprendre des langages de code, quel intérêt dès lors de forcer des développeurs à apprendre un para-langage super-spécifique ?
1-c. Les non-codeurs, par essence, ne devraient pas avoir à coder. Pour coder, et même pour faire de l'intégration, embauchez des codeurs, ils feront du travail plus propre. Les designers, ils font le design, au mieux ils découpent des éléments pour les codeurs, et ça suffit déjà à les occuper s'ils sont compétents.
1-d. La coloration syntaxique, il faut qu'elle soit adaptée à la nouvelle syntaxe. Ou alors faut coder en daltonien.
2-a. Ca ne facilite pas la maintenance de forcer les mainteneurs à connaître un langage en plus. En fait ça le complique.
2-b. Le moteur de template va évoluer. Faut-il répercuter les évolutions ? Ca coûte du temps inutile tout ça, ça apporte des risques d'effets de bord, et ça rapporte généralement rien de concret. Sauf quand ça corrige des bugs. Donc on le fait quand même ?
2-c. De même que pour développer des vues c'est mieux d'avoir un développeur, pour les maintenir ça peut même être critique. Les vues évolues en se compliquant quand on les laisse suivre leur nature, il faut un bon jardinier pour élaguer les branches mortes sans couper les branches importantes et faire un beau jardin.
3- On peut très bien automatiser les mises en cache sans besoin de moteur de template. Il suffit de faire des conventions claires et de définir un point de passage obligé pour le traitement des vues.
4-a. Au final, au mieux ça va faire baisser la productivité le temps que les développeurs acquièrent l'outil, au pire ça va la plomber durablement parce que les développeurs ne prennent pas le temps d'apprendre les petites subtilités qui permettraient de gagner du temps.
4-b. Et surtout, en utilisant un bon langage et en factorisant on obtient les mêmes effets positifs sur la productivité.
Bref, le moteur de template c'est un peu un pansement sur la béquille d'une personne qui a deux jambes bien portantes.