Jump to content

[PROPOSITION] Passer smarty en gestion array pour une sortie des tpls en fin traitement


Recommended Posts

Bonjour à tous,

Ceci n'est qu'une proposition qui viserai à améliorer les possibilités de développement des modules.

Objectifs :
Permettre aux développeurs de modules de recharger un contenu prévu en sortie smarty avant le lancement de l'entête html. En plus des hooks actuels (pas encore assez nombreux), il serai intéressant de pouvoir manipuler à tout moment dans le traitement de la page courante, la sortie des tpl vers smarty.

Constat sur le noyau de PrestaShop actuellement :
Le noyau actuel appelle des tpl vers smarty au moment où il doit les traiter. Pour exemple, voici la séquence actuelle, pour une page tel que l'index.php (l'accueil) :

<?php
[...]
include(dirname(__FILE__).'/header.php');
[...]
$smarty->display(_PS_THEME_DIR_.'index.tpl');
[...]
include(dirname(__FILE__).'/footer.php');
?>


[...] : tronquage de code volontaire.

Le header.php lui-même fait appel à :

[...]
$smarty->display(_PS_THEME_DIR_.'header.tpl');


et pour finir, le footer.php termine la sortie des tpl de smarty par :

[...]
$smarty->display(_PS_THEME_DIR_.'footer.tpl');



Ce qui signifie clairement que les templates sont donc traités et envoyés au moment du traitement php.
En d'autres termes, à peine avoir terminer le traitement php du serveur, que l'entête HTML est déjà en queue dans le httpd et n'est plus modifiable (car déjà envoyée).

J'ai vu beaucoup de CMS et autres codes faire les mêmes pratiques. Moi-même, j'ai commencé avec cette méthode d'envoi direct des sorties tpl.

Un problème se pose :
Le fait d'envoyer l'entête HTML avant même la fin du traitement final du php, ne nous donne pas la possibilité de revenir en arrière pour rendre le code encore plus modulable et/ou modulaire. L'exemple simple serai de pouvoir décharger un appel tpl pour en recharger un de remplacement avec des fonctionnalités supplémentaires et des variables personnalisées.

La solution :
J'avais personnellement déjà travaillé sur ce problème pour un CMS admin qui aujourd'hui fait se preuve tant en stabilité qu'en performances.
L'idée serai de modifier dans le noyau chaque déclaration du type :

$smarty->display([REPERTOIRE].'fichier.tpl');


par une mise en tableau sur un simple array() que j'appellerai $smarty_exit, avec cette solution :

$smarty_exit[] = array(
               'path' => 'PATH_DES_REPERTOIRES_TPL',
               'file' => 'fichier.tpl'
               ); 


Ce code permet donc d'ajouter dans l'ordre de ses déclarations, des clés portants le nom du fichier, et leur valeur associée qui représente le chemin de parcourir où se situe le fichier tpl en question (celui de la clé).

En fin de code, et uniquement à la fin, il ne reste plus qu'à charger les sorties des tpl passées en revue pendant le traitement php.
Voici un exemple de sortie que l'on pourrait envisager :

if ($smarty_exit) {
   foreach($smarty_exit as $tpl => $tpl_path) {
       $smarty->template_dir = $tpl_path['path'];
       $smarty->display($tpl_path['file']);
   }
}




Mes camarades développeurs comprendrons certainement l'utilité de ma proposition, qui permettrait à chacun de pouvoir retoucher comme bon lui semble le tableau $smarty_exit, pour y loger tous ses traitements modulaires.

J'ajoute aussi que cette solution s'adapterait facilement au noyau actuel.

C'est bien sûr dans un soucis d'amélioration de nos possibilités en développement que je me permets de vous soumettre cette proposition.

Qu'en pensez-vous ?

Bien cordialement à tous

Link to comment
Share on other sites

$smarty_exit['fichier.tpl'] = 'PATH_DES_REPERTOIRES_TPL';

si par exemple tu as un template navigation.tpl que tu veux charger avant et après ta liste de produit, avec ton tableau, tu ne peut pas mettre deux fois la même référence ?


Effectivement pour l'aspect purement fonctionnel.

On peut ainsi l'améliorer comme suit :

$smarty_exit[] = array(
               'path' => 'PATH_DES_REPERTOIRES_TPL',
               'file' => 'fichier.tpl'
               );



en fin de traitement :

if ($smarty_exit) {
   foreach($smarty_exit as $tpl => $tpl_path) {
       $smarty->template_dir = $tpl_path['path'];
       $smarty->display($tpl_path['file']);
   }
}



Ainsi on peut recharger tous les tpl à l'infinie.

Link to comment
Share on other sites

Voila,
Par contre il faut faire attention, si au lieu de prendre navigation, on prend des produits (produit.tpl), les variables smarty changent pour chaque template, et la ça pose un problème.
Il faut donc qu'ils soient intégré dans un template supérieur (list-produit.tpl) , qui se charge de parcourir tous les produits et charger tous les templates produit.tpl

Link to comment
Share on other sites

template liste-produit.tpl
tu as un array avec tes produits, tu boucle dessus, et pour chaque produit tu charge produit.tpl qui sert juste à l affichage d'un produit.


je suppose que tu parles de cette partie en fin de product.tpl :

{if $packItems|@count > 0}

{l s='Pack content'}
       {include file=$tpl_dir./product-list.tpl products=$packItems}

{/if}



C'est un appel de page directement inclue dans le tpl. J'arrive pas à comprendre ce qu'il poserai problème ?

Link to comment
Share on other sites

  • 2 months later...

Bonjour,

Je fais remonter ma proposition, car je pense qu'elle est de plus en plus d'actualité.

Cette proposition reste une réelle avancé pour tous les développements. Elle offre une vraie possibilité pour améliorer, moduler à l'infinie PrestaShop.

Bien cordialement

Link to comment
Share on other sites

Je plussoie l'idée, mais bon ! tout développeur un peu astucieux a déjà plus ou moins adapté quelque chose pour éviter ce problème, et le reste des personnes ne seront pas intéressées (à juste titre) par cette idée.

Tu as déjà un résultat à montrer ? Il serait intéressant de présenter un cas concret. En clair, tu veux pouvoir modifier les variables d'un Template appelé dans un include PHP ?
C'est surtout le cas pour le header et le footer. Cela peut être une bonne idée. C'est sur qu'on se retrouve souvent avec des tests un peu bof dans nos templates pour identifier la page en cours et modifier par exemple l'affichage du menu.
Enfin, ai-je bien compris ?

Link to comment
Share on other sites

Enfin, ai-je bien compris ?


Bonjour,

Non c'est pas ça du tout.
La méthode que je propose permet de reprendre la main sur tout le code de A à Z avant le réel envoi de l'entête html. Ce qui veut dire que quelque soit ce que PrestaShop génère dans son traitement, tant que l'entête html n'est pas sortie du httpd, on est en mesure de retoucher tout le code, ou qu'il soit, php ou smarty. Ce qui offre une possibilité infinie de développement pour retravailler tout ce que l'on veut au moment ou l'on veut dans le code.

Bien cordialement
Link to comment
Share on other sites

Bonjour

Si j'ai bien compris le système, on passerait en dehors du système de cache de Smarty (et autres systèmes de cache) lors de la sortie ce qui pose un problème de performances...


Bonjour,

Pas du tout, tout reste à l'identique dans la compilation smarty. Simplement, au lieu que les pages tpl soient chargées en plein traitement à n'importe quel moment (et c'est la le problème), elles sont chargées à la fin du traitement php par :

if ($smarty_exit) {
   foreach($smarty_exit as $tpl => $tpl_path) {
       $smarty->template_dir = $tpl_path['path'];
       $smarty->display($tpl_path['file']);
   }
} 



Les options de cache et autres, reste toujours dans le config/smarty.config.inc.php.
Mais je comprends que cette proposition puisse freiner PrestaShop car elle supposerai de revoir chaque sortie smarty :

$class->smarty->display($le_tpl_path.'le-tpl-en-cours.tpl');


et de le remplacer par :

$smarty_exit[] = array(
               'path' => 'le_tpl_path',
               'file' => 'le-tpl-en-cours.tpl'
               ); 



Enfin bon, c'est pas non plus la mer à boire. Avec une équipe de 4 à 5 développeurs en 20 min c'est fait.

Link to comment
Share on other sites

Si ma mémoire est bonne (mais je peux me tromper), le cache smarty est créé en fonction de certains paramètres (template, id produit, id groupe client etc. en fonction des pages) donc si on change le contenu sans changer ces paramètres, lorsque le cache sera activé, les modifications ne seront pas prises en compte à l'affichage : à vérifier !

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...