Réécrire PluXML et utiliser un moteur template

Dakin Quelia

Bonsoir à toutes et à tous,

J'ai en projet de réécrire le code de PluXML pour séparer le php et le HTML. Pourquoi? Car c'est plus facile de maintenir le thème que ce soit celui de l'administration (backend) que celui de la partie publique (frontend). De ce fait, j'utilise le moteur template Twig (j'ai déjà utilisé pour un petit projet que j'avais commencé).

Je trouve que c'est plus sympa si chaque chose est à sa place et ça permet aux auteurs de thème de pouvoir mettre à jour facilement leur thème sans devoir tout recommencer à zéro puisqu'étant donné que dans la partie HTML il n'y aura que les variables du genre :

{{ ma_variable }}.

Voilà. :P

Bien à vous

Gzyg

Salut,

Et le faire SANS template, ce ne serait pas possible ?

L'un des gros intérêts de PluXml (comme WordPress, d'ailleurs) est justement de ne pas utiliser de template comme Twig ou Smarty... qui sont quand même des usines à gaz.

Déjà, simplement se débarrasser de plucss et nettoyer l'html existant (notamment les attributs title non modifiables dans les liens serait une grosse avancée. ]:D

Dakin Quelia

Twig n'est pas forcément une usine à gaz.

Tout est possible à faire sans. Mais le résultat ne sera pas identique.

Par ailleurs, structurer un programme n'est pas une mauvaise chose.

Bien que PluXML soit génial, le code php mélangé au HTML fait que c'est lourd à gérer pour les mises à jour, que ce soit pour le moteur PluXML lui-même autant que pour le style de l'utilisateur. D'ailleurs, je suis pour séparer le php / html.

Quant à PluCSS il n'est pas forcément mauvais. Il a du potentiel.

Pour ce qui est du plus gros intérêt et essentiellement cela réside dans le fait, non pas d'avoir un moteur de template ou non, mais de pouvoir gérer des articles / pages sans base de données et de ce fait, plus facilement portable.

kowalsky

Et pour les gens qui utilisent leurs propres thèmes, ça se passera comment ?

bazooka07

Et tu gères les hooks comment ?
Si plus de hook, plus de plugin !

Le souci de PluXml côté admin, c'est qu'il utilise les "echo" par grandes rafales. Du coup, cela devient parfois pénible à lire.

Pour éviter d'avoir à utliser un moteur de template et de conserver l'attrait des hooks, c'est d'utiliser la syntaxe HereDoc.
Il suffit juste de préparer avent l'appel à HereDoc, les variables qui vont bien.

Pour les plugins quand il y a besoin d'injecter du code, j'utilise la syntaxe SimpleDoc couplée avec la fonction strtr pour remplacer des mot-clés par les bonnes valeurs.

Une autre alternative serait d'utiliser des outils comme VueJS mais c'est un gros chantier. Déjà que l'on a du mal à intégrer les modifications du gestionnaire de medias que j'ai apportées !

Dakin Quelia

En fait, je remodifie les classes php pour séparer le HTML et nettoyer un peu le code.

Les hooks seront toujours présents et les plugins ainsi aussi.

Dakin Quelia

kowalsky a écrit:

Et pour les gens qui utilisent leurs propres thèmes, ça se passera comment ?

Il faudra dès lors s'adapter. Mais ce n'est pas tellement contraignant, c'est juste qu'il n'y aurait plus de php dans le template. Mais plutôt ça :

[== HTML ==]
{% extends 'layout.html' %}

{% block content %}
	
	<article class="article">
		<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque eu arcu a ipsum ultrices venenatis eget sed lacus. Curabitur vel felis faucibus, sodales quam a, consequat nulla. Donec sit amet ante arcu. Mauris finibus eget nisl vitae commodo. Morbi sit amet sapien diam. Quisque ut risus cursus nisi efficitur pharetra. Sed feugiat, magna a pretium pretium, sapien enim laoreet risus, varius efficitur libero quam ut mauris. In ut tortor orci. Aliquam congue efficitur aliquet. Aliquam consequat est nec risus eleifend lacinia. Donec dolor erat, accumsan sit amet viverra ut, ultricies eu risus. Etiam purus leo, ultrices sit amet massa molestie, mollis sodales turpis. In sapien urna, posuere nec arcu non, finibus tempor quam. Morbi tincidunt, quam quis tempor condimentum, neque diam laoreet augue, id malesuada ex mauris vitae elit. Proin lobortis nunc ac lacinia placerat. Nullam blandit condimentum nulla, non bibendum arcu tempus at.</p>

		<p>Sed id scelerisque nibh, sit amet ultrices lacus. Sed condimentum neque arcu. Curabitur id arcu non lorem imperdiet egestas. Morbi ut pretium tortor. Cras quis velit sed felis congue sodales. Fusce eu ornare velit, et elementum odio. Quisque neque sem, sagittis non tortor vel, tincidunt vulputate metus. Vestibulum fermentum iaculis urna a mollis. Cras hendrerit porttitor mauris, quis ultrices diam tempus in. Maecenas at scelerisque velit. Curabitur in metus accumsan ligula vehicula vehicula. Sed in ligula in risus ullamcorper euismod in non sem. Suspendisse potenti. Nunc pellentesque pharetra dui, eget euismod risus dignissim id.</p>
	</article>

{% endblock %}

bazooka07 a écrit:

Et tu gères les hooks comment ?
Si plus de hook, plus de plugin !

En fait, je remodifie les classes php pour séparer le HTML et nettoyer un peu le code.

Les hooks seront toujours présents et les plugins ainsi aussi.

bazooka07

S'il n'y a plus de PHP, je ne vois comment tu vas faire pour conserver les hooks.
El plus, il y a des plugins qui utilisent des variables de PluXml quand ils font de l'injection de code.
Le plus simple est d'utiliser la syntaxe HereDoc. Il y a plus de garantie d'assurer une rétro-compatiblité avec les plugins qui sont dans la nature.

flipflip

Je réfléchi pas mal aussi à comment séparer le php du html. Au début les moteurs de templates me paraissaient être la solution magique et plus je et plus je me rends que c'est déplacer le problème.

En gros à la place d'avoir du code php on aura du code spécifique au moteur de templates... C'est un peu pareil du coups.

Le seul avantage que je vois à passer sur un moteur de template connu est la facilité, pour un intégrateur, à créer un template. Car si il connaît Smarty ou autre il n'aura pas apprendre la logique, c'est la même. Juste à récupérer les bonnes variables.

Pourquoi ce séparer de PluCSS ? Je trouve l'idée bonne même si il reste encore du boulot pour arriver à un knaccss qui est vraiment léger et fonctionnel. La question pourrait être, pourquoi pas utiliser knaccss et participer au dev ?

Gzyg

flipflip a écrit:

Pourquoi ce séparer de PluCSS ... il reste encore du boulot pour arriver à un knaccss qui est vraiment léger et fonctionnel

La réponse est dans la question ! Pourquoi réinventer une roue qui tourne déjà bien et dans le bon sens ?
PluXml, je pense, à d'autres priorités sur lesquelles mettre l'énergie disponible des développeurs.

Quand au templating genre "smartwig"... pour moi, c'est radicalement non ! Je préfère encore WordPress et son foutu Gutenberg ! :P

Jerry Wham

Gzyg a écrit:

[Quand au templating genre "smartwig"... pour moi, c'est radicalement non !

Clairement. Php est déjà un système de template par définition. Pourquoi réinventer la roue ?
En tout cas, si vous basculez vers ce type de solution, je n'utiliserai plus PluXml.

Si vous souhaitez vraiment séparer la logique de la présentation, le seul système que je connaisse et qui tienne la route est celui de Tom Buttler :
[list=*]
[*]https://r.je/transphporm-php-templates.html[/*]
[*]https://github.com/Level-2/Transphporm[/*]
[/list]
Il utilise de l'html pour l'affichage et un code qui se rapproche du css pour la logique...

Quelle que soit la solution choisie, vous perdrez tout ce qui fait la simplicité de PluXml en introduisant des risques supplémentaires de bugs.

Rien n'empêche par contre de faire un peu de ménage.

@bazooka07 : je ne vois pas en quoi utiliser HereDoc plutôt que les balises php, améliorerait la situation. En plus de ça, tous les éditeurs de code ne reconnaissent pas forcément cette syntaxe et la considère comme du commentaire.

Haruka

Bonjour à tous,

Même si je suis curieux de voir le résultat des travaux de Dakin, je ne souhaite pas basculer PluXml sur ce type de solution, pour toute les raisons qui ont été exposées ci-dessus. Il y a certainement des optimisations à faire dans l'organisation et/ou dans l'écriture du code, mais je veux conserver ce qui fait l'identité de PluXml depuis le début, à savoir sa légèreté et sa simplicité.

bazooka07

Jerry Wham a écrit:

@bazooka07 : je ne vois pas en quoi utiliser HereDoc plutôt que les balises php, améliorerait la situation. En plus de ça, tous les éditeurs de code ne reconnaissent pas forcément cette syntaxe et la considère comme du commentaire.

Si ton éditeur de code ne reconnait pas la syntaxe HereDoc, change le. Ce n'est pas le choix qui manque :
[list=*]
[*]Geany[/*]
[*]Vim[/*]
[*]Netbeans[/*]
[*]Visual Studio Code[/*]
[/list]
C'est utilisé par de nombreux langages.
A la différence d'autres langages, PHP permet la substitution de variables dans la syntaxe Here Doc : Lire le manuel !!!!
Je n'ose pas te parler de syntaxe simple ou complexe de variables ]:D

Dakin Quelia

Bonjour à toutes et à tous,

Je comprends les différents points de vue de chacun et je les respecte.

P3ter a écrit:

Bonjour à tous,

Même si je suis curieux de voir le résultat des travaux de Dakin, je ne souhaite pas basculer PluXml sur ce type de solution, pour toute les raisons qui ont été exposées ci-dessus. Il y a certainement des optimisations à faire dans l'organisation et/ou dans l'écriture du code, mais je veux conserver ce qui fait l'identité de PluXml depuis le début, à savoir sa légèreté et sa simplicité.

Oui, je t'enverrai tout cela quand ce sera fini. Et j'ai justement dans l'optique d'optimiser le code par ailleurs.

Bien à toi

Jerry Wham

bazooka07 a écrit:

Jerry Wham a écrit:

@bazooka07 : je ne vois pas en quoi utiliser HereDoc plutôt que les balises php, améliorerait la situation. En plus de ça, tous les éditeurs de code ne reconnaissent pas forcément cette syntaxe et la considère comme du commentaire.

Si ton éditeur de code ne reconnait pas la syntaxe HereDoc, change le. Ce n'est pas le choix qui manque :
[list=*]
[*]Geany[/*]
[*]Vim[/*]
[*]Netbeans[/*]
[*]Visual Studio Code[/*]
[/list]
C'est utilisé par de nombreux langages.
A la différence d'autres langages, PHP permet la substitution de variables dans la syntaxe Here Doc : Lire le manuel !!!!
Je n'ose pas te parler de syntaxe simple ou complexe de variables ]:D

Ce n'est pas parce que plusieurs langage l'utilisent que ça signifie qu'il faille absolument l'utiliser...
Heredoc en php, comme les guillemets doubles, ralentissent la lecture du code par php car il doit analyser s'il doit ou non interpréter les variables. Et si comme tu le dis, tu avais lu le manuel, tu aurais sûrement vu que "La façon la plus simple de spécifier une chaîne de caractères est de l'entourer de guillemets simples (le caractère '). "(sic)
Rien dans ce que j'ai lu me donne d'argument incitant à utiliser heredoc ou les guillemets doubles plutôt que les simples.

Mais si tu en as, je suis toute ouïe.

Gzyg

Euh... bazooka07 et Jerry Wham... voilà une discussion qui mériterait un fil pour elle seule (et pour ne pas polluer celui-ci) car ça peut partir loin... ]:D

Pour résumer :
[list=*]
[*]réécriture du code pour simplification : OK[/*]
[*]moteur de template php : KO[/*]
[/list]

À vous les studios !

je-evrard

La puissance de vuejs pour la partie admin est réellement très (très) puissante.

Voici une vidéo d'une application que j'ai faite dernièrement intégralement en vuejs mono app avec des composants maison :

Digital Signage Engine

A noter que je vais utiliser la même techno pour mon futur cms.

++

jéjé