Php et prestashop

Bonjour, …en fait bonsoir, ou bonne nuit (faut que je me couche)
 
Bon je me suis mis à php. Ma petite question (toutes les autres j’ai fini par y répondre, pour l’instant, mais là je sèche): j’ai fait un petit module, qu’on va appeler monmodule, qui fonctionne, tout au moins la partie backoffice que j’ai réalisé.
 
Là j’ai fait un override de Product.php, pour commencer à réaliser le front office, et j’essaye d’appeler une fonction de monmodule et là c’est le drame. Je précise que le module n’est pas instancié du côté front office.
 
C:\wamp\www\prestashop\modules\monmodule\monmodule.php:

<?php
....
class MonModule extends Module
{
   // fonction qui sert dans le module, qui fonctionne, mais qui ne veut pas être appelée de l'extérieur
     public function getMesDonnees($id_product)
    {
          return Db :: getInstance() -> executeS('SELECT  * FROM .....            );
         }
    ....
}

C:\wamp\www\prestashop\override\classes\Product.php:

<?php

class Product extends ProductCore
{
 	 // reprise du    getProductsProperties en rajoutant une colonne dans le $row
   public static function getProductsProperties($id_lang, $query_result)
	{
		$results_array = array();

		if (is_array($query_result))
			foreach ($query_result as $row)
				if ($row2 = Product::getProductProperties($id_lang, $row))
 		             {
 		                  $toto=Monmodule::getMesDonnees((int)$row2['id_product']);
		                   $row2['manouvellevariabledansProduct']=$toto;
		       	   $results_array[] = $row2;
		                }
				return $results_array;
	}
}

J’ai beau essayer toutes les écritures, $this-> , $monmodule= new MonModule() et $monmodule->getMesDonnees(), ou Monmodule::getMesDonnees(), rien n’y fait j’ai invariablement Class Not Found.

Je précise que c’est aussi une occasion de me mettre à la POO. :slight_smile: Je veux dire qu’il y a là peut-être une évidence. J’ai lu qu’il fallait éviter les static mais de toute façon même en static ça ne marche pas, car ça plante au niveau même de la reconnaissance de la class, il ne la connait définitivement pas.

Je m’y suis au php pour dépanner sur prestashop et en fait c’est un langage amusant et puissant, idem pour Jquery. Donc j’ai modifié un module. Puis là j’en créé un petit.
 
Prestashop est un peu bordélique, il y a plein de fonctions qui ne resservent pas. Par contre facile à utiliser du côté de l’utilisateur. C’est la version 1.5.4. Et les modules ne font pas 4km donc c’est bien pour se mettre au php sans être perdu.

merci de votre aide :slight_smile:

A mon avis te mettre à PHP, Prestashop et POO en même temps, c’est peut-être un peu trop. Il faudrait déjà que tu captes bien la POO, puis le langage PHP pour enfin pourvoir rentrer dans Prestashop.

Si personne ne répond d’ici lundi, je pourrais demander un coup de main d’un collègue dans ma boite qui bosse sur ce soft, car personnellement, je ne sais pas comment PHP et Prestashop gère l’équivalent du “Classpath” en Java.

ya tellement de pbs (wtf with the statics ?) et tellement de questions (namespace ? require ? instanciation de module ?) sur ton soucis que je ne sais meme pas comment commencer à résoudre ton pb.

Deja, faut que tu regle le soucis de class not found, surement les namespace si t’es en PHP >5.2 sinon un require manquant quelquepart.
Ensuite, dans monmodule, getMesDonnees appelle une static. (db::getinstance), pk tu appelles pas directement db::getinstance depuis product ?

Merci à vous 2 :slight_smile:
 

[quote=« ZGoblin, post:2, topic: 55152 »][/quote]

hô l’autre ;). Après avoir fait une petite évolution, rajouter un champ dans un module, je me suis attaqué à plus gros en faisant un back office de module de A à Z en partant des tutos. Et ça marche en plus en utilisant les nouveautés de Prestashop 1.5 c’est-à-dire les helperForm (qui à partir d’un array créent un formulaire et gère les updates automatiquement). :stuck_out_tongue:
 
Prestashop a un code pas très propre mais en revanche compréhensible. Le php venant de Delphi et de Python ce n’est vraiment pas compliqué. En fait si je me suis mis à php c’est surtout pour me mettre à l’architecture n-tiers et de comprendre la POO dont j’avais lu  des cours théoriques mais jamais mis en application (je faisais du Delphi procédural facilité par l’interface RAD).
 

[quote=« ZGoblin, post:2, topic: 55152 »][/quote]
 
En fait c’est surtout pour comprendre les portées car j’ai l’impression que les fonctions des modules même en public ne sont pas atteignables, d’ailleurs même le nom de la class n’est pas reconnu. A moins sans doute que mon module soit instancié, j’imagine, mais comme il ne me sert qu’à remplir une table et qu’il ne sert pas en Front Office sauf cette fonction de SELECT.
 
Donc ne prend pas trop la tête à ton collègue, c’est pour de l’autoformation, en revanche s’il a une explication des portées des modules je prends :slight_smile: Que ça soit en php en général et surtout dans prestashop.

D’ailleurs a priori la nouvelle façon de mettre directement les overrides dans le répertoire du module ne fonctionne  pas (même en forçant le rafraichissement de class_index.php, en le supprimant, dans C:\wamp\www\prestashop\cache). Donc pour pouvoir développer sans me tromper dans les mises à jour j’ai fait comme sous unix (avec ln) un lien sous windows avec mklink que j’ai découvert: en liant mon fichier php dans le répertoire de mon module d’override vers le répertoire « officiel » qui marche /prestashop/override/classes.
 

[quote=« Donjohn, post:3, topic: 55152 »][/quote]
Oulà ben j’ai tout essayé. Il faut que je comprenne que c’est un namespace ? Peut-être que c’est en relation avec l’architecture même de prestashop et que c’est voulu pour les modules.

En attendant voilà comment j’ai résolue mon souci: en déplaçant ma fonction dans Product (dans l’override pour être précis). Après le souci c’est comme beaucoup de vieille fonction de prestashop sont écrites en procédural, on est obligé de les recopier entièrement, j’en ai donc pris une sur le trajet des données qui soit petite.


C:\wamp\www\prestashop\modules\monmodule\monmodule.php:

<?php
....
class MonModule extends Module
{
  
     protected function getMesDonnees($id_product)
    {
          return Product::getMesDonnees ($id_product);
         }
    ....
}

C:\wamp\www\prestashop\override\classes\Product.php:

<?php

class Product extends ProductCore
{
 	 // reprise du    getProductsProperties en rajoutant une colonne dans le $row
   public static function getProductsProperties($id_lang, $query_result)
	{
		$results_array = array();
		if (is_array($query_result))
			foreach ($query_result as $row)
				if ($row2 = Product::getProductProperties($id_lang, $row))
 		             {
 		                  
		                   $row2['manouvellevariabledansProduct']=Product::getMesDonnees((int)$row2['id_product']);
		       	   $results_array[] = $row2;
		                }
				return $results_array;
	}
     public static getMesDonnees($id_product)
    {
          return Db :: getInstance() -> executeS('SELECT  * FROM .....            );
    }
}
En fait je pourrais faire 2 fonctions différentes, une dans le Back Office comme avant, et un copier coller dans le Front Office.

Comme l’une me sert au helper dans le back office, et donc doit renvoyer strictement les colonnes voulues, tandis que l’autre dans le Front Office pourrait me servir à aller chercher d’autres données en plus.

Mais c’est aussi pour comprendre les portées et la POO et la notion de classe et c’est pas propre de copier-coller la même fonction tant que c’est factorisable.

edit: ortho

t’as fait du procédurale (en utilisant des static partout) dans des classes… (en résumé : tes classes ne servent à rien)

Je pense qu’il te manque les notions de base de la POO, je commencerai par là avant de me replonger dans prestashop ou tout autre systeme en php objet.

Les namespace sont une notion de programmation objet (arrivé sur le tard en php…), tu appelles les namespaces des fichiers dont tu as besoin, c’est pour alleger/rendre dynamique les chargement de librairies. Chaque fichier que tu crées est assigné à un namespace (mot clé namepsace en debut de classe) et ensuite tu appelles les namespaces dont tu as besoin (mot clé use). C’est quasi la meme chose qu’un require mais à un niveau plus bas de programmation, tu require des classes et non des fichiers contenant des classes/fonctions.

[quote=« Donjohn, post:5, topic: 55152 »][/quote]

Ma petite fonction est certes en static faute de mieux, d’où l’objet de ce topic, mais il faut savoir que Prestashop est critiqué pour être écrit, sauf les derniers apports de la dernière version, en simili-procédural avec des static partout. En fait à certains endroits, surtout les endroits centraux mais en fait ancien, c’est un vrai plat de nouilles: des fonctions qui sont refaites à plusieurs endroits, des fonctions dont les fonctionnalités se baladent entre plusieurs classes, etc… j’ai eu du mal à à trouver juste ce qui m’intéressait.

En d’autres termes, c’est pas moi c’est lui (Prestashop). :smiley:

Ce qui fait plutôt que de surcharger un objet, il y a certes des overrides mais on ne peut en fait que surcharger la class car les fonctions sont des patés énormes qu’il faut recopier et modifier, et qui fait qu’on ne peut utiliser les capacités de la POO sauf dans les helpers.

La fonction public static function getProductsProperties est une fonction « de base » de prestashop non touchée par moi sauf la ligne en question.
 

[quote=« Donjohn, post:5, topic: 55152 »][/quote]

Si je me suis mis à prestashop c’est d’abord pour dépanner quelqu’un de ma famille qui fait de l’intégration prestashop côté charte graphique. Après je me suis pris au jeu qu’au lieu de rajouter un champ, j’allais créer un module. Et ça m’a permis de comprendre le développement n-tiers.
 
Mais le souci c’est qu’en fait, à part certaines nouvelles fonctionnalités, une grande partie de prestashop n’est pas écrit en php objet. Par exemple Product.php est une classe remplie de fonction qui se suivent qui sont écrites en procédural.
 
Donc effectivement pour la POO prestashop n’est pas le CMS le plus adapté pour comprendre la POO, non pas car ça serait trop compliqué de comprendre en même temps la POO et prestashop, mais tout simplement en raison du fait que prestashop n’est pas écrit en POO du tout à certains endroits.
 

[quote=« Donjohn, post:5, topic: 55152 »][/quote]

Ok je comprends mieux qu’il y a des trucs pour gérer la portée.

Après c’est en faisant de la maintenance qu’on acquiert les bases. Mais maintenant il faudrait que je me fasse une petite appli autonome qui fasse à peine plus que hello world mais en vrai php objet. Et ensuite me faire les dents sur un cms vraiment en POO.

edit: en tout cas, même si c’est une maigre consolation du point de vue de la POO, mon module est écrit de la même façon que les autres modules.

L’idéal est de faire de la vraie POO mais je serais aussi curieux d’avoir l’avis du collègue de ZGoblin sur prestashop, en fait du principe de réalité: pas au top de la POO mais un succès certain côté client donc aussi beaucoup utilisé par les indépendants graphistes mais aussi certaines ssii orientées commerce électronique pour les PME.

edit:ortho

POO et php : symfony 2. Il a des cotés très compliqués notamment sur les injections et le firewall mais c’est du VRAI objet, voir limite mieux que le php natif (gestion des singleton bien mieux qu’en php).

Et je confirme, prestashop c’est de la grosse merdasse niveau code. Je l’ai toujours fuit comme la peste. Ca marche donc c’est utilisé mais le moteur est hyper moche :wink:

[quote=“Donjohn, post:7, topic: 55152”][/quote]

Depuis j’ai suivi la formation de cakephp de grafikart (très pédagogique, ni trop complexe, ni basique), puis en partant de cette base j’ai fait un petit site entier, le tout en faisant de la  POO (avec d’autres formations sur la POO en général, puis sur la POO en php en particulier).

Et effectivement plus j’en apprends, plus je vois que le développement de Prestashop est une sorte de fuite en avant qui fait fis de toutes les bonnes pratiques de programmation. Sans parler de la documentation qui est aussi mince qu’une feuille de papier à cigarette, qui fait qu’une majorité des développeurs n’utilisent pas leurs helpers (en tout cas si j’en crois les sources des modules que j’ai eu sous les yeux).

Ce qui est bien avec cakephp c’est qu’il est loin d’être aussi complexe que Symfony, tout en étant objet et avec une bonne structure MVC. Mais comme il reste relativement léger il permet plus facilement  l’apprentissage que Symfony qui est très très complexe. Ça m’a permit aussi de mieux comprendre les bases de php et les échanges entre les différentes couches logiciels et les bonnes pratiques MVC et objets. En plus la documentation est plutôt bien faite et exhaustive  (v2.5.x courante), sans parler de la version 3 en préparation (la beta vient de sortir) prenant en compte les dernières nouveautés de php.

En fait Prestashop est le cas typique du cas de conscience technique, cas que j’ai souvent rencontré en ssii dans mon domaine de la bdd et de la BI, où le marketing et le commercial en ont fait un produit qui a du succès et qui génère du chiffre d’affaire pour Prestashop et les développeurs, mais dont la base technique est malheureusement un plat de nouilles avec certaines méthodes qui font plusieurs centaines de lignes, et plein de méthodes en static, cela à cause du manque de temps et de méthodologie allouée à la technique par la direction: priorité aux nouvelles fonctionnalités et la rapidité du dév.

En fait il faudrait que Prestashop ait une structure proche de cakephp dans sa conception, sans être aussi complexe que Magento, qui est d’ailleurs trop gros pour la majorité des TPE.