Jump to content

Gestion du theme pour les controller supprimant les colonnes


Recommended Posts

En 1.5, le tunnel de commande est géré sans la colonne de gauche.

 

Lors du paiement par virement, un Front Controller du module bankwire s'affiche, sans cette colonne de gauche.

Cela est possible car une variable de ce controller indique que cette colonne ne doit pas être affichée.

 

class BankwirePaymentModuleFrontController extends ModuleFrontController
{
   public $display_column_left = false;

 

Quelle est la technique pour développer un thème qui garderait la colonne de gauche et supprimerait celle de droite ?

 

Comment surcharger ces frontController situé dans les modules ?

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Bonsoir,

on ne peut pas malheureusement, ce qui est très dommage je suis d'accord. A mon sens ce type de configuration devrait d'une part être gérée dans le thème, mais aussi toucher à tous les modules de paiement d'un coup et pas seulement à quelques controllers alors qu'au final ils auront tous ces propriété.

Link to comment
Share on other sites

Si j'ai bien compris la réponse, si on veut un thème avec les modules de paiement qui laissent la colonne de gauche plutôt que la droite, il faut modifier les modules correspondant dans le coeur de Prestashop ?

 

Sur addons, je propose un module de paiement.

Par défaut, je le livre donc comme les autres modules de paiement (qui masque la colonne de gauche).

Ensuite l'intégrateur du site modifiera la variable dans mon module ?

Link to comment
Share on other sites

Personnellement, je faisais ce que je voulais avec les colonnes avec des conditions smarty (pour la colonne de droite qui ne peux etre que dans le footer) ou avec l'insert du code {$HOOK_LEFT_COLUMN} dans les tpl où j'en ai besoin.

 

V++

 

Atch

Link to comment
Share on other sites

Ce que j'en comprends, c'est qu'en 1.4, les hook de colonnes étaient appelés et que le smarty décidait ensuite d'afficher ou non la colonne.

 

En 1.5, avec ce display_column_left, c'est le controller qui décide s'il faut afficher la colonne ou non. Cela a pour effet de ne pas appeler les hooks.

en FrontController.php :

$this->context->smarty->assign(array(

'HOOK_HEADER' => Hook::exec('displayHeader'),

'HOOK_TOP' => Hook::exec('displayTop'),

'HOOK_LEFT_COLUMN' => ($this->display_column_left ? Hook::exec('displayLeftColumn') : ''),

'HOOK_RIGHT_COLUMN' => ($this->display_column_right ? Hook::exec('displayRightColumn', array('cart' => $this->context->cart)) : ''),

));

 

Ca devrait être au theme de décider quelles colonnes il affiche en fonction du controller actif, plutôt qu'au controller de décider des colonnes qui lui sont liées.

 

 

En tant que développeur de module, lorsque je développe un module qui ajoute un controller dans la partie "Mon compte " en front offcie, je ne peux pas présumer sur combioen de colonne il s'affiche. C'est le theme qui décide.

Par surcharge des tpl et css, le theme spécialise mon module. Il devrait pouvoir faire de même pour l'affichage des colonnes.

  • Like 1
Link to comment
Share on other sites

bonjour,

avec

$this->display_column_left ou $this->display_column_right

On peut choisir d'afficher ou pas les colonnes au niveau du controller, avant de faire appel au thème, ce qui est sans doute mieux au niveau performance mais moins souple au niveau du thème.

Bien qu'une mise en cache des pages gomme cette différence.

Link to comment
Share on other sites

  • 1 month later...

Ce que j'en comprends, c'est qu'en 1.4, les hook de colonnes étaient appelés et que le smarty décidait ensuite d'afficher ou non la colonne.

 

En 1.5, avec ce display_column_left, c'est le controller qui décide s'il faut afficher la colonne ou non. Cela a pour effet de ne pas appeler les hooks.

[...]

Ca devrait être au theme de décider quelles colonnes il affiche en fonction du controller actif, plutôt qu'au controller de décider des colonnes qui lui sont liées.

De ce que je vois, dans 1.5, c'est les tpl (Smarty) qui decident de l'affichage des colonnes ou non.

Si ton tpl appelles $HOOK_RIGHT_COLUMN et $HOOK_LEFT_COLUMN, tu as tes colonnes. Sinon, tu ne les as pas.

 

Comme le faisait remarquer Chantane, $this->display_column_left et $this->display_column_right sont la pour ameliorer les performances.

Pourquoi recuperer toutes les donnés d'une colonne si c'est pour ne pas l'afficher.

 

Par default, $this->display_column_left et $this->display_column_right sont settés a true, donc si tu ne touches a rien au niveau des controllers mais que tu vires $HOOK_RIGHT_COLUMN du tpl, la colonne de droite ne n'affichera pas mais tu auras quand meme fait tout le processing pour.

Inversement, si tu sets $this->display_column_right = false dans ton controller, mais que tu gardes $HOOK_RIGHT_COLUMN dans ton tpl, tu affiches quand meme la colonne de droite mais elle est vide.

 

Resultat, tu peux changer le tpl sans changer le controller, ou l'inverse, ou changer les 2.

Link to comment
Share on other sites

Tu dois pouvoir faire comme avant en modifiant le tpl. Mais ce n'est pas forcément la meilleure solution.

Tu faisais comment avant?

 

Suivant ce que tu veux faire et le ratio flexibilité/optimisation que tu veux, tu joues soit sur le controller, soit sur le tpl, soit sur les 2 (solution ideale dans la plupart des cas je pense).

 

Par exemple, si tu veux degager la colonne de droite pour la page contact (quelque soit la langue), tu peux dire au contoller (le ContactController) de ne pas aller chercher les données pour cette colonne (en settant $this->display_column_right = false). Cela ne fait pas disparaitre la colonne de ta page, mais elle est vide.

Ca c'est pour le coté optimisation.

 

Apres tu dois faire des modificaitons au niveau presentation pour pas avoir un block vide qui saccage ton design.

Et la, tu as la tout plein de solutions que tu peux mixer.

La solution propre est d'utiliser Smarty pour ne pas afficher le block quand tu demandes la page contact. C'est dans le header.tpl si tu utilises le theme par defaut. Ca peux faire un peu comme quand tu ajoutes une exception dans le back office pour ne pas afficher un module je pense (ce n'est qu'une intuition, je n'ai pas regardé le code).

Moins bien, tu peux degager le block en javascript.

Pire, tu peux le faire avec les CSS mais c'est a éviter je trouve (a utilser juste si ca presse et que c'est pour un cas isolé).

 

Si maintenant, tu ne veux pas afficher la colonne de droite de la page contact suivant la langue, la logique est la meme mais un peu plus de code est necessaire.

Dans ce cas la, tu peux ne pas modifier le controller et mettre la logique uniquement au niveau de l'affichage (tpl). Ca n'est pas forcement ideal, mais si tu dois ajouter la logique au controller, il est alors preferable de mettre les valeurs des langues dans la base de donnees plutot que de les hard coder dans le code PHP et la, ce te fait tout de suite beaucoup plus de travail..

 

Comment vous faites vous?

Link to comment
Share on other sites

Il faut utiliser les layouts

 

dans un thème, créer un dossier override.

 

Ensuite, placer des fichiers selon la convention de nommage layout-{entity}.tpl.

Par exemple, pour définir un layout custom pour la home page, le fichier sera nommé layout-index.tpl

 

Le truc c'est que le thème par défaut de PrestaShop est un très mauvais exemple !

C'est principalement pour assurer la rétrocompatibilité.

Link to comment
Share on other sites

Ce qui serait bien, ce serait que tu puisses définir au niveau du thème (dans le fichier config.xml par ex), l'affichage des colonnes pour chaque page.

 

Ensuite, il faudrait que cette config définisses les valeurs de $display_column_left et $display_column_right.

 

Donc en gros :

- PrestaShop lit le fichier de config du thème et le met en cache

- Dans chaque controller, on définit l'affichage des colonnes en fonction de ça

Link to comment
Share on other sites

A premiere vue, il doit suffire d'overrider le getLayout() dans le controller associé a la page pour laquelle tu ne veux pas du layout.tlp par defaut.

Genre dans IndexControllerCore, tu mets

public function getLayout()
{
return _PS_THEME_OVERRIDE_DIR_.'monTplRienQuAmoiPourLaPageDaccueil.tpl';
// comme je vois pas trop l'interet d'avoir le repertoire override, on peut meme faire ca:
//return _PS_THEME_DIR_.'monTplRienQuAmoiPourLaPageDaccueil.tpl';
}

A tester.

Edited by Erikku (see edit history)
Link to comment
Share on other sites

C'est inutile de faire ça, c'est une fonctionnalité qui peut être gérée de manière centralisée.

Quel interet? Si le layout depend du controller alors autant laisser le controller le choisir? Ca eviterait la lourdeur du getLayout() dans le FrontControllerCore.

La, quand tu as un objet du type IndexControllerCore par exemple, il est obligé demander sa classe mere (FrontControllerCore) de lui dire qui il est, alors qu'il le sait deja lui quelque part..

Link to comment
Share on other sites

Je veux dire, pas besoin de recoder ça à chaque fois.

 

Exemple débile avec un vieil array :

 


$controllersColumns = array(
   'index' => array('left' => false, 'right' => false), 
   'category' => array('left' => true, 'right' => false)
);

// Au moment du dispatching, modifier les controllers avec les valeurs configurées

 

Ensuite ça tu le fous au niveau du thème et roule. Avec ton système, ça impacte tous les thèmes.

 

Or, tu veux pouvoir afficher/masquer des colonnes thème par thème.

 

Tiens, ça mériterait un module gratuit tout ça ^_^

Link to comment
Share on other sites

Je comprends pas ce que tu veux dire.

Tu veux recoder quoi a chaque fois?

Dans ce que je disais, tu overrides juste la function getLayout() si celle par default ne te convient pas.

Elle fait une ligne de code dans mon example.

 

Le fait d'avoir a faire des if pour verifier un type (celui du controller) c'est pauvre comme design dans un langage orienté objects.

Link to comment
Share on other sites

Le fait d'avoir a faire des if pour verifier un type (celui du controller) c'est pauvre comme design dans un langage orienté objects.

 

Oui oui je sais :)

 

Dans ce cas précis, ce n'est pas vraiment la classe mère qui connait ses implémentations...

C'est plutôt qu'on se base sur des conventions de nommage, et c'est le cas dans tous les frameworks MVC modernes, les controllers sont nommés {Action}Controller.

 

Ici, ce n'est pas vraiment un problème de conception : chaque instance de FrontControllerCore est dédié à une page, et chaque page sait si elle doit afficher les colonnes ou non. Ceci peut être gérée de manière centralisée, car le fonctionnement en mode colonnes est au coeur de PrestaShop, malheureusement.

Link to comment
Share on other sites

Il faut dire ce que tu ne comprends pas et posez des questions.

Solution 1, tu suis le link mentionné post #26 et tu poses tes questions labas.

Solution 2, que je trouve plus fexible, tu vas dans \override\controllers\front et pour chaque page pour laquelle tu veux un affichage special, tu edites le controller correspondant en mettant la fonction mentionnée au poste #19, a savoir:

public function getLayout()
{
	return _PS_THEME_OVERRIDE_DIR_.'monTplRienQuAmoi.tpl';
	// comme je vois pas trop l'interet d'avoir le repertoire override, on peut meme faire ca:
	//return _PS_THEME_DIR_.'monTplRienQuAmoiPourLaPageDaccueil.tpl';
}

Et tu crées un nouveau tpl 'monTplRienQuAmoi.tpl' avec l'affichage que tu souhaites pour la page en question.

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

En checkant sur la 1.5.1 :

 

C’est le fichier FrontController.php qui détermine le contenu des colonnes, par l’initialisation smarty suivante, dans sa méthode initContent() :

$this->context->smarty->assign([b]array[/b](
  'HOOK_HEADER' => Hook::[i]exec[/i]('displayHeader'),
  'HOOK_TOP' => Hook::[i]exec[/i]('displayTop'),
  'HOOK_LEFT_COLUMN' => ($this->display_column_left ? Hook::[i]exec[/i]('displayLeftColumn') : ''),
  'HOOK_RIGHT_COLUMN' => ($this->display_column_right ? Hook::[i]exec[/i]('displayRightColumn', [b]array[/b]('cart' => $this->context->cart)) : ''),
));

 

Le header.tpl reçoit donc toujours cette variable HOOK_LEFT_COLUMN, renseignée ou non par des appels de hooks.

Sous-entendu, le thème fait le nécessaire suivant le controller pour adapter le CSS de la colonne.

 

Plutôt que d’utiliser un paramètre codé en dur dans chaque controller, pourquoi ne pas profiter des exceptions qui sont gérées sur les hooks ?

En back-office, en éditant le hook ColonneDeGauche, il est possible d’exclure l’exécution pour certains controller.

Cette méthode me parait plus élégante : lors de son installation, un theme modifie la BDD pour mettre les controller voulus en exception sur les colonnes droites et gauche. Pas besoin de modifier le code des controller.

Au bémol près, j'avoue, que les exception sont gérées par module et non pas globalement pour tous les modules. Donc si on installe un moduel après le thème, il ne profite pas de l'eception.

Mais on pourrait imagine une exception globale à tous les modules, non ?

 

Au passage, je n’ai pas compris d’où venait la liste des controllers proposés pour les exceptions. Pas sûr qu’il y ait tous les controlleurs, y compris ceux définis par les modules.

Link to comment
Share on other sites

  • 1 month later...

Bonjour,

 

et si nous souhaitons créer, par exemple, un layout pour une catégorie définie

il suffit de nommer dans le dossier override de notre thème : layout-category-6.tpl ? (pour la catégorie 6 par exemple)

 

Pareil pour les produits?

 

Merci

Link to comment
Share on other sites

Viiii, pour une fois que le code est bien commenté, faut aller jeter un oeil!

class/controller/FrontController.php (around line 1070):

/**
 * Returns the layout corresponding to the current page by using the override system
 * Ex:
 * On the url: http://localhost/index.php?id_product=1&controller=product, this method will
 * check if the layout exists in the following files (in that order), and return the first found:
 * - /themes/default/override/layout-product-1.tpl
 * - /themes/default/override/layout-product.tpl
 * - /themes/default/layout.tpl
 *
 * @since 1.5
 * @return bool|string
 */
public function getLayout()

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