Salut,3WAcademy - Semaine 10 - logo

Après une semaine 10 compliquée à ne pas avoir compris grand chose et fini dans un état de fatigue avancé, cette semaine s’est beaucoup mieux passée!

Nous sommes à fond dans le projet et après avoir passé l’intégralité du lundi à faire l’autiste, casque vissé sur la tête pour comprendre comment fonctionnait le framework, j’ai enfin compris! Comme quoi, un week end à ne pas trop toucher un clavier ça permet de digérer une semaine un peu difficile! J’en ai profité pour envoyer mes dernières demandes de stage, j’espère que j’aurais des retours et que je pourrais continuer mon apprentissage dans de bonnes conditions. Vu les entreprises dans lesquelles j’ai postulé, ça devrait bien se passer dans tout les cas!

Le projet avance et de 3 nous nous retrouvons à 2, ce qui est un peu dommage mais on va faire avec, ou plutôt sans… Mon collègue peine un peu avec le calendrier, j’espère qu’il va y arriver. De mon côté je n’ai pas trop mal avancé, j’ai quasiment respecté mon planning.

Nous avons aussi eu une petite introduction à GITHUB, que je n’avais jamais utilisé, il va falloir que je pratique pour être plus à l’aise. Tu peux d’ailleurs voir l’avancement du projet sur GITHUB. Il est assez moche, mais c’est pas le sujet. Je sais pas si à seulement 2 on auras le temps de faire du CSS…

Je vais travailler sur ce projet ce week end afin de continuer d’avancer dans les fonctionnalités que nous avions définies et d’essayer de le rendre plus beau, c’est quand même un projet de fin d’étude!

Developpement

Le framework: j’ai compris!

Il m’aura fallut 2 jours pour comprendre le framework. Le premier, vendredi dernier, passé à écouter les explications du formateur, qui au passage est un expert sur Symfony… Ensuite, j’ai passé l’intégralité de mon lundi à faire de petit test pour voir le fonctionnement de FEAR, c’est comme ça que j’ai baptisé le framework en fin de semaine dernière…Il existe un framework PHP qui s’appelle PEAR, ça m’a inspiré…

L’organisation des fichiers

Un des premiers points qui me posaient problème la semaine dernière était l’organisation des fichiers en fonction des cas d’utilisations. Par exemple imaginons que nous voulons créer un compte client. Ce sera un cas d’utilisation pour notre site de e-commerce.

Dans le dossier controller il faut créer un dossier create_customer qui contiendra un fichier PHP que l’on appellera CreatecustommerController.class.php. Voici comment est organisé le nom du fichier:

  • Createcustomer : nom du cas d’utilisation,
  • Controller : indique que c’est un controller
  • .class.php : indique que c’est un objet PHP qui contient un certain nombre de propriétés et de méthodes.

Ce principe est applicable aux deux autres composantes du MVC, le Modèle et la Vue. Dans le dossier Model, on va créer pour chaque cas d’utilisation un fichier particulier. Pour notre exemple, le nom du fichier sera : CreatcustomerModel.class.php

Pour la vue, le principe est le même: CreatecustomerView.phtml.

Je pense que tu commences à comprendre le principe de l’organisation des fichiers. Alors il faut faire attention à la casse des noms, il faut que ça soit de cette forme tout le temps. J’ai eu des soucis un peu bizarre avec le CamelCase, donc c’est pour cette raison que je ne l’utilise pas pour ça.

En gros, à chaque fois qu’on démarre l’écriture de code pour un nouveau cas d’utilisation il faut préparer ces fichiers,  faire attention au nom qu’on donne et le reste se passe bien. 

Les routes

Une fois que les fichiers correspondant au controller, au model et à la vue, le framework s’occupe de les associer par défaut grâce à leur nom (il y a bien sur possibilité de faire une redirection vers un autre controller, grâce à une méthode PHP prévue par le framework).

Il y a une méthode dans le framework qui s’occupe de « découper » ou d’analyser l’url de la requête et de la faire correspondre avec un controller. Après il n’y a rien de magique non plus, c’est ce qui me posais problème la semaine dernière le framework c’est un bitier de multiprise sur lequel on vien se brancher pour avoir de l’électricité. Il est très important de bien nommer les fichiers et de bien veiller à diriger l’information vers le bon controller.

Exemple:

J’ai un bouton d’envoi de formulaire. Au clic je transmets les informations du formulaire en méthode POST (à condition d’avoir renseigné cette méthode…). Ensuite il faut que l’url de l’attibut action de la balise form, pointe vers le controller CreatecustommerController.class.php, par exemple, qui a la responsabilité de traiter les données de ce formulaire.

Une fois que ce controller reçoit le contenu de la requête http POST, on appelle une méthode que l’on a écrite dans le model CreatecustommerModel.class.php, qui permettra de faire une requête SQL pour écrire sur la base de donnée avec une méthode INSERT INTO.

Enfin le model va transmettre une réponse au controller, qui la traitera et permettra d’afficher par exemple sur la vue que le formulaire a bien été enregistré.

Ce qu’il faut bien comprendre la dedans, c’est qu’on a juste à écrire des méthodes assez courtes et précises, qui ne font pas forcément beaucoup de chose et que le framework se charge de faire communiquer les différents fichiers entre eux. C’est assez simpliste mais il m’a fallu un peu de temps pour comprendre ce que ça faisait et comment. Une fois que j’ai eu compris ça, effectivement on n’a pas besoin de comprendre chaque ligne de code qui compose le framework pour pouvoir l’utiliser.

Le début de l’écriture du code d’un oplmmmmmcas d’utilisation est assez répétitive. On commence par la création des fichiers controller, model, vue. Ensuite on a juste besoin de savoir quelle méthode http utiliser et de ne pas trop se planter dans le code…

L’utilisation du framework m’a permis de mieux comprendre l’utilisation des objets, puisqu’on écrit beaucoup moins de code, on l’organise mieux, et je trouve même que j’ai fait moins d’erreur. En fin de semaine j’ai eu très peu besoin des conseils du formateur, ce qui n’était clairement pas le cas la semaine dernière…

Voyons maintenant un peu plus en détail la structure de chaque type de fichier, toujours calquée sur le modèle MVC. Pour faire un peu l’analogie avec le schéma de la semaine dernière, je te conseille de rejeter un oeil sur le schéma de la semaine dernière concernant le modèle MVC (3WAcademy – Semaine 10).

Le controler

Le controller est un objet qui possèdera toujours 2 méthodes, dans le cadre du framework de la 3WAcademy:

  • httpGetMethod
  • httpPostMethod

Ces méthodes sont définies par le framework et ont besoin de 2 paramètres pour fonctionner :

  • http : indique le type de méthode HTTP utilisé pour la requête,
  • array : un tableau comprenant toutes les données transmises par l’action de l’utilisateur depuis la vue précédente.

Suivant les controllers, je n’ai pas forcément eu besoin des 2 mais elles apparaissent toutes les deux par défaut dans mes objets. Avec ce framework, on ne récupère jamais les méthodes globales de PHP $_POST ou $_GET,  puisqu’il se charge de les « transformer » en tableau que l’on récupère dans la méthode correspondante (GET ou POST) de chaque controller.

Les controllers ont le cas échéant la responsabilité de reformuler le tableau qui arrive pour le transmettre à une autre méthode située dans un objet Model qui exécutera une requête SQL. Le framework utilise des requêtes SQL préparées. Le controller nous permet de vérifier comment lui arrivent les données et de les remodeler afin que chaque information passe bien au bon endroit dans la requête. Dommage  d’avoir une erreur lors de la requête quand on a pas vérifier qu’on était en train de stocker une chaine de caractère alors qu’on attends un entier dans la base. Le controller permet aussi de faire des vérifications de données avant l’envoi sur la bases de données. Si on détecte une erreur, on peut rediriger vers la page initiale et demander à ce que l’utilisateur reprennent sa saisie. Comme nous l’a souvent dit le formateur: « NE JAMAIS FAIRE CONFIANCE A L’UTILISATEUR! » Je ne sais pas si je vais avoir le temps de traiter toutes les vérifications dans tous les controller qu’il va falloir que j’écrive. Je pense que je continuerai à travailler sur ce projet après mon départ de l’école…

Et la base de donnée?

Avec ce framework la connection à la base de donnée (qui est aussi stockée dans un objet ) se fait dans le controller. La méthode du model a besoin d’être connecté donc on passe un nouvel objet Database en paramètre de l’objet model que l’on va utiliser (voir exemple ligne 35). Encore une fois tu peux voir à quoi ça ressemble sur GitHub, il te suffit d’ouvrir n’importe quel controller (Projet-code_de_départ /www/application/controllers).

Ci-dessous, l’extrait de code du controller permettant de récupérer les données saisies par l’utilisateur lors de la création de son compte.

C’est le premier controller que  j’ai écrit. Je verrais si j’ai assez de temps pour faire des tests sur les types de données et faire du hachage de mot de passe avant l’exécution de la requête…

<?php
/**
 * Objet permettant de créer un nouveau compte utilisateur
 *
 */

class CreateaccountController
{

/**
 * [httpGetMethod description]
 * @return [method] [réalise les requetes GET]
 */
public function httpGetMethod(){

  }

/**
 * [httpPostMethod description]
 * @param  Http   $http        [indique le type de requete, dans ce cas POST]
 * @param  array  $queryFields [tableau contenant le contenu du formulaire d'inscription]
 * @return [type]              [description]
 */
  public function httpPostMethod(Http $http, array $queryFields){

    $values = [];
    $values['nom'] = $queryFields['nom'];
    $values['prenom'] = $queryFields['prenom'];
    $values['mail'] = $queryFields['mail'];
    $values['adresse'] = $queryFields['adresse'];
    $values['cp'] = $queryFields['cp'];
    $values['ville'] = $queryFields['ville'];
    $values['mdp'] = $queryFields['mdp'];

    $new_account = new CreateaccountModel(new Database());


    $result = $new_account->write($values);


  }

};

Le Model

Par défaut le constructeur de l’objet Model est constitué de 2 méthodes:

  • une pour écrire sur la base,
  • une autre pour lire.

Encore une fois, suivant le cas d’utilisation on peut avoir besoin d’autres méthodes pour mettre des données à jour (UPDATE) ou pour les supprimer (DELETE).

L’objet Model contient autant de méthode qu’il y a de requête à réaliser pour ce cas d’utilisation.

Pour notre exemple je vais avoir besoin d’écrire sur la base de donnée pour créer l’utilisateur avec une méthode INSERT INTO, puis d’une autre requête pour récupérer les données du client lorsque celui-ci sera connecté. Ces informations seront ensuite stockées dans le $_SESSION qui assurera la transmission des données de connections de l’utilisateur.

Les réponses des requêtes sont ensuite retransmises au controller qui les renvoient en général sous forme de tableau vers une Vue (fichier phtml).

Je m’arrête rapidement sur ce format de fichier un peu bizarre, le phtml. Ne cherche pas une doc ou dans la littérature, tu ne trouveras pas de trace du phtml. C’est une convention de l’école pour indiquer que ces fichiers html contiennent du code PHP. Le formateur nous a d’ailleurs indiqué qu’il avait plutôt l’habitude d’utiliser des fichiers .html.php, mais ça fonctionne pareil.

Ci-dessous,  exemple de mon premier objet Model permettant d’écrire sur la BDD.

<?php

class CreateaccountModel extends AbstractModel{


/**
 * Méthode permettant de créer l'utilisateur
 * Ecriture sur la base de donnée
 * @param array contenant les caractéristiques de l'utilisateur
 */
    public function write(array $values){
        // var_dump($values);
        $sql = "INSERT INTO client(nom, prenom, mail, adresse, cp, ville, mdp)
        VALUES(:nom, :prenom, :mail, :adresse, :cp, :ville, :mdp)";
        $this->database->executeSql($sql, $values);
    }


// Faire méthode pour la récupération des données et permettre la modification des information de l'utilisateur
	
	    public function read(array $values){

  	}
}
 

Les vues

L’avantage de préparer ses fichiers à l’avance comment j’en ai parlé plus haut c’est que ça évite les erreurs déclenchées par le framework, t’expliquant que le fichier attendu n’existe pas. C’est  très pratique de travailler comme ça, puisque parfois, tout marche du premier coup et tu passes à la suite. Le framework a le chemin complet, ou devrais-dire la route vers tous les fichiers pour ce cas d’utilisation du coup plus de problème de ce côté là. Il y a certain fichier View dont je ne me sers plus puisque j’ai besoin de rediriger certaines informations vers d’autre page (d’autres controllers). Au moins je me dis qu’en ça de problème, ces fichiers serviront de roue de secours, puisque si la redirection ne fonctionne pas, grâce à la vue, j’aurais quelque chose à l’écran, ce qui évitera d’avoir une erreur… 

Les vues (fichiers .phtml) permettent de mélanger du html et du php. Par exemple, c’est dans ces fichiers que je fais des boucles pour passer des données contenues dans un tableau PHP vers des balises HTML puis les mettre en forme. J’intègre donc des variables PHP dans des balises HTML. C’est très efficaces, pratique, et c’est pour moi un des points fort de PHP.

L’exemple suivant m’a permis de créer dynamiquement la liste des menus du restaurant dans un tableau HTML. Je créé autant de ligne dans le tableau qu’il y a de menu et dans chaque menu j’affiche autant d’informations qu’il y en a de stockée dans le tableau PHP, d’où les boucles foreach imbriquées. Tu vois bien dans cet exemple que le code PHP est mélangé au HTML. Pour voir à quoi cela ressemble, tu peux jeter un oeil au code sur GitHub.

<?php 
//Méthodes du framework permettant de faire passer les données de sessions
$new_session = new Usersession();
$check_log = $new_log->isAuthenticated();


<table class="generic-table">
      <thead>
                <tr>
                  <td>Listes des menus</td>
                </tr>
                <?php
              foreach ($menus as $array) {
                ?>
                <tr>
                      <?php
                      $id_menus = array_slice($array, 0, 1, false);

                      $edit_list = array_slice($array, -5, null, false);
                    
                      foreach ($edit_list as $key => $value) {

                        ?>
                      <td>
                            <strong><?= str_replace("_", " ", ucfirst($key)); ?></strong>
                      </td>
                  <?php
                  };break;// deuxième foreach
                  ?>
                </tr>
                <?php
                };// 1er Foreach
                ?>
      </thead>
  <tbody>
            <?php
            foreach ($menus as $array) {
            ?>
              <tr>
                  <?php
                  $id_menus = array_slice($array, 0, 1, false);
                  
                  $edit_list = array_slice($array, -5, null, false);
                  

                  foreach ($edit_list as $key => $value) {

                  ?>
                    <td>
                          <?php
                          if($value == $array['nom_menu']){
                          ?>
                              <a href="<?= $requestUrl ?>/editmenu?id_menus=<?= $id_menus['id'] ?>"><?= str_replace("_", " ", ucfirst($value)); ?></a>
                          <?php
                          }// if
                          else{
                          ?>
                                  <?= str_replace("_", " ", ucfirst($value)); ?>
                          <?php
                          }// else
                    }// 2eme foreach
                          ?>
                    </td>
              </tr>
              <?php
              };// 1er Foreach
              ?>
  </tbody>
</table>

Bilan de la semaine

En cette fin de semaine j’ai réalisé les cas d’utilisations suivant:

  • créer un compte utilisateur,
  • se connecter / se déconnecter en tant qu’utilisateur,
  • se connecter / se déconnecter en tant qu’administrateur,
  • Afficher une barre de navigation différente que l’on soit un client ou un administrateur, on accède évidemment pas aux mêmes pages,
  • je peux créer des menus et les ajouter dans la base de données, les modifier et les supprimer,
  • j’affiche la liste des menus dans une page de l’administration, au sein d’un tableau,
  • j’affiche les menus mis en forme sur la page d’accueil de la partie utilisateur ainsi qu’un bouton qui va me permetttre de passer des commandes.

 Réconcilié avec le framework

Après un mois de PHP et SQL, j’ai mis 4 jours à faire ça, je n’ai malheureusement aucune idée du temps qu’il faudrait mettre pour faire ça en entreprise. Ce qui m’ennui un peu c’est que je ne vais pas avoir le temps de régler des détails, faute de combattant… pour rappel, on est passé de 3 à 2… donc on va devoir se répartir le travail pour pouvoir fournir la partie commande qui est selon moi la plus compliquée…

En tout cas le fait d’être en groupe réduit me permet de toucher à tout sur ce projet, ce qui me convient très bien, même si ça doit me faire une charge de travail supplémentaire. Je commence à bien m’amuser avec ce framework, je me rends compte du temps que je gagne grâce à lui. Je suis assez content parce que même si c’est pas le projet de l’année, j’arrive à produire quelque chose, c’était mal parti la semaine dernière, j’étais beaucoup moins optimiste…. Mon seul regret va être le manque de temps, je sais que je ne pourrais pas finir… Il y a un groupe de quatre dans la promo et ils vont faire un super projet, j’ai hâte de voir le résultat!

Il me reste qu’une semaine à la 3WAcademy, la semaine prochaine on passe le fameux QCM, et je me mets un peu la pression, je me méfie des QCM… ON a fait un QCM blanc proposé par le formateur. Il nous a confié que son QCM était plus dur que celui de la 3WA… J’ai eu la moyenne pile, ça promet…

Je te souhaite un bon week end, à bientôt!

Guillaume