Gérer mes variables

Bonjour,

J'essaye de concevoir un site, au début je me suis penché sur l'aspect design et tout allait bien, puis je me suis concentré sur l'aspect contenu (bdd) et je me suis aperçu que les codes que j'utilisais ne fonctionnaient plus sous variables.

J'utilisais un javascript d'affichage de divs concernant mon menu (catégorie de produits) et les produits en eux memes, car je connaissais leur intitulé en avance. Maintenant, je suis carrément perdu.

Mon code contient un div top (menu) et un div (contenu). j'aimerais que tous les produits s'affichent au démarrage (et donc plus de display) et se filtrent lorsque je clique sur une catégorie du menu.

Je cherche à jouer avec le "select from where" mais je suis perdu pas niveau compétence mais plutot niveau organisation du code^^'

Code MENU !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<div id="top"> CHO <img src="images/logo_choping.gif" height="45px" width="50px"/> PING <div class="bouton_menu"> ☰ </div>       <div id="menu"> <td><li> <?php $conn = mysqli_connect('); $req = "SELECT distinct categorie FROM produit"; $res = $conn->query($req); while ($data = mysqli_fetch_array($res)) { echo '<a>'.$data['categorie'].'</a>';} mysqli_close($conn); ?>   </li></td> </div> </div>

---

CODE CONTENU :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<div id="catalogue"> <?php $conn = mysqli_connect(); $req = "SELECT * FROM produit";   $res = $conn->query($req);   while ($data = mysqli_fetch_array($res)) { echo '<div id="produit"><form method="post" action="" class="jcart"><input type="hidden" name="jcartToken" value='.$_SESSION['jcartToken'].'/> <input type="hidden" name="my-item-id" value='.$data['id'].' /> <input type="hidden" name="my-item-name" value='.$data['nom'].' /> <input type="hidden" name="my-item-price" value='.$data['prix'].'/> <input type="hidden" name="my-item-qty" value="1" /> <input type="hidden" name="my-item-url" value="http://yahoo.com" /> <li><strong>'.$data['nom'].'</strong></li> <li>'.$data['prix'].'</li> <li><input type="submit" name="my-add-button" value="add to cart" class="button" /></li></form></div>';} mysqli_close($conn); ?> </div>

---

Le site est accessible ici : Cho Ping

Merci de votre aide,

PS : Le panier ne fonctionne plus depuis que le prix n'est plus un nombre (00.00) mais une variable due a la protection du code..

Je ne suis pas un professionnel du Web, mais j'ai eu une formation : donc ma réponse n'est pas forcément la meilleure ni la bonne :aie:

C'est la méthode objet, mais tu peux la faire tout pareil en procédural :mrgreen:


1) La base de donnée - un objet CRUD :
Il y a plein de façons de faire mais cet objet CRUD va se connecter à ta base et aura au moins 4 méthodes : Create, Read, Update, Delete

• Create (requête SQL insert) attend 3 tableaux associatifs ou 3 chaînes de caractères : 1 pour la liste des colonnes, 1 pour le nom de la table, 1 pour les valeurs
• Read(requête SQL select) attend 3 tableaux associatifs ou 3 chaînes de caractères : 1 pour la liste des colonnes, 1 pour le nom de la table, 1 pour la clause WHERE
• Delete (requête SQL delete) attend 2 tableaux associatifs ou 2 chaînes de caractères : 1 pour le nom de la table, 1 pour la clause WHERE
• Update (requête SQL update) attend 3 tableaux associatifs ou 3 chaînes de caractères : 1 pour les nouvelles valeurs, 1 pour le nom de la table, 1 pour la clause WHERE

Moi je n'aime pas cette façon : je préfère un objet avec une grosse interface spécifique à mon programme : connect_membre, insert_article, ...

L'avantage du CRUD (surtout si tu fais le truc ultra-complet avec des requêtes préparées, les clauses ORDER BY, les jointures, ...) tu la copies/ colles dans tous tes projets.
L’inconvénient principal, c'est que tous les objets l'utilisant vont devoir "parler SQL"

2) Les entités :
Tu vas avoir une classe par table (sauf table associative si c'est une relation 1..1) : chaque champs va correspondre à un attribut de classe, souvent privé, avec les accesseurs/ mutateurs (getter/ setter)
C'est le gros débat sur Internet : c'est le modèle anémique (parce qu'elle n'a pas de logique). Mais tu peux y ajouter de la logique.
Cette classe va être utilisée par les objets "repositories" : suite à un résultat SQL, ils vont le convertir en collection d'entités pour la transmettre aux contrôleurs.

3) les objets "repositories" :
Ils sont là pour gérer des collections d'entités. Ils vont interroger la base via le CRUD, convertir en collection d'entités et la retourner au contrôleur appelant.
Pour qu'1 "repository" appelle le CRUD, je ne sais pas trop :koi: : soit le CRUD est un singleton soit faire de l'agrégation/ composition - injection de dépendance (via le constructeur ou avec un accesseur)
Par contre, il me semble bien que les objets "repositories" soient des singletons.

4) Les modèles :
En théorie, ils héritent du CRUD et ils sont liés à une entité.
Ils permettent d'interroger la base au sujet d'une entité : pour récupérer les informations d'un profil/ membre, pour supprimer un article, pour tester si un membre existe, ...
Et comme les objets "repositories", ils retournent une entité au contrôleur appelant.
Par contre, je ne suis pas sûr qu'ils soient réellement utiles si on a des objets "repositories", et ce sont des attributs des contrôleurs (composition) ou en variables locales

4.bis) Les "domain objects" (D.O.) - les services (???) :
Si je ne dis pas de bêtises, un modèle est lié à une entité alors qu'un D.O./ service ne l'est pas.
Les modèles ont une logique CRUD alors qu'un D.O./ service lui va contenir de la logique métier.

5) les contrôleurs :
C'est la route qui va créer le contrôleur. Et une fois créer, il va travailler (interroger la base de donnée soit via un modèle soit via des "repositories", avoir la logique métier, ...) et instancier un "template vue"
C'est sûrement lui (mais pas sûr à 100%) qui vérifient les données passées en entrée, avant de les donner à la base.

Donc dans cette architecture, on a en gros pour chaque entité : entité + son contrôleur + son "repository" [+ son modèle (si utile)]


6) les vues :
Dans cette architecture, les vues sont réduites à de simples fichiers (twig, php, ...) : c'est du HTML avec un peu de php ou 1 langage template pour générer le contenu, afficher les informations.
Mais c'est aussi un autre débat : tu peux faire de vrais objets vue, mais ce sont les objets contrôleurs qui vont avoir moins de choses à faire (dans un sens c'est logique - le contrôleur peut très bien ne pas gérer l'affichage et que ce soit un objet vue qui interroge le modèle)

7) "front controller" + les routes :
Apparemment, ce sont les requêtes REST qui sont utilisées avec des méthodes POST, GET, UPDATE, ...
Une route, c'est une URL + la méthode + les paramètres.
Et dans ton code, tu vas avoir un "front controller" qui va parser une route et ainsi créer le bon contrôleur ou alors renvoyer un code erreur 404/ ...

Et pour que cela fonctionne, il faut rediriger toutes les routes vers le fameux index.php, le point d'entrée de ton "back end" MVC. Tu fais cela avec Apache, et le fichier .htaccess


8) L'API :
Ton "back end" peut aussi renvoyer des données (JSON, XML, ...) au lieu d'une page HTML
Disons que la route est du style : GET http://XXX/api/YYY/?param01=value01&param02=value02
Là je pense que c'est soit le contrôleur qui doit savoir retourner différents résultats (HTML, JSON, XML, ... avec le bon header content type) soit faire des contrôleurs spécial API


Et donc ton problème est simple : lorsque tu génères ta liste de catégories, pour chaque catégorie tu vas créer un lien du style : http://XXX/items/list/?category=YYY ou http://XXX/category/list_items/?name=YYY

Et donc ton code aura à peu près cette exécution lorsque ce lien catégorie sera appelé : front controller -> instanciation du bon contrôleur [-> appel d'un "repository"] -> requête avec un "WHERE category_name = YYY" -> récupération du résultat sous forme tableau associatif ou tableau d'entités -> instanciation du template "view_one_category.XXX" -> renvoi au client

Merci quand même