- PHP >= 7.1.*
- Composer
- MySQL avec PDO
Par sa simplicité, MVC4 requière peu de configuration pour fonctionner.
MVC4 est livré avec un fichier nommé config/config-dist.php. Ce fichier est destiné à être versionné, et ne doit pas contenir d'informations personnelles ou sensibles. Le fichier lu par défaut par le framework est config/config.php, qui lui, ne doit pas être versionné, il vous est personnel.
Pour démarrer copier-coller le contenu du fichier config/config-dist.php dans
/* config/config.php */
return array(
'db_name' => 'dbname',
'db_user' => 'root',
'db_pass' => '',
'db_host' => 'localhost',
'directory' => '/chemin/to/view/'
);
Les routes permettent d'associer simplement des URL virtuelles à des pages spécifiques de votre site. Plus précisémment, elles vous permettent d'exécuter une méthode de contrôleur que vous avez choisie
Toutes les routes doivent être définie dans le fichier /config/routes.php
'index.php?page=nameofpage&id=.'$id Les contrôleurs sont au coeur de vos applications. Ce sont eux qui traitent les requêtes et les formulaires, font appel au "modèle" pour manipuler les données, exécutent la logique applicative, et finalement, retournent des réponses (habituellement une vue, des données brutes ou une redirection) au client.
Vous pouvez créer autant de contrôleurs que vous le souhaitez. Pour vous donner une idée, il est fréquent d'avoir autant de contrôleurs que vous avez de table dans votre base de données (bien que ce ne soit nullement une règle à appliquer strictement). Ainsi, pour un blog, il y aurait probablement, a minima, un PostController, un CommentController et un UserController.
Toutes vos classes devraient être sous l'espace de nom App\Controller et hériter (directement ou non) de la classe App\Weblitzer\Controller, afin de bénéficier des méthodes fournies.
Il est essentiel de parcourir vous-même la classe App\Weblitzer\Controller, afin d'avoir un portrait juste de tout ce qu'elle vous offre.
En quelques mots, sachez qu'elle vous permet de gérer les redirections et les urls, l'envoi de réponses de vue, de pages d'erreurs et de JSON.
Pour chacune des "pages" de vos applications, une méthode de contrôleur devrait être définie. C'est notamment pour cette raison que vous ressentirez le besoin de créer plusieurs contrôleurs, afin de "classer" vos méthodes, qui deviendront rapidement nombreuses.
Ces méthodes doivent être de visibilité public, et devrait normalement se terminer par l'une des actions suivantes :
=> /app/Model/* app/Controller/DefaultController.php */ public function index() { //autre logique ici, puis... /** * Méthodes habituellement utilisées en fin de traitement du contrôleur *///affiche un template $this->render('app.default.contact'); //affiche un template, tout en rendant des données disponibles dans celui-ci //template disponible dans le dossier view/app/default/contact.php $this->render('app.default.contact',['username' => 'michel']); //redirige vers une page du site $this->redirect('index.php?page=contact'); //redirige vers un site externe $this->redirect('https://weblitzer.com'); //retourne une réponse JSON //... $data = []; $this->showJson($data); //retourne une erreur 404 $this->Abort404();
}
Les modèles (ou Model) sont les classes responsables d'exécuter les requêtes à votre base de données.
Concrètement, chaque fois que vous souhaitez faire une requête à la base de données, vous devriez venir y créer une fonction qui s'en chargera (sauf si elle existe déjà dans les modèles de base du framework).
Dans votre application, vous pourriez avoir un modèle par table MySQL (sans obligation). Chacune de ces classes devraient hériter de App\Weblitzer\Model\, le modèle de base du framework, qui vous fera profiter de quelques méthodes utiles pour les requêtes simples à la base de données.
Par exemple, pour créer un modèle relié à une table fictive de commentaires nommées comment :
<?php /* app/Model/CommentModel.php */
namespace App\Model;
class CommentModel extends \App\Weblitzer\Model
{
protected static $table = 'comments';
protected $comment;
protected $created_at;
protected $status;
//Récupère les commentaires associés à un article
public function findPostComments($postId)
{
//...
}
}
Voici les propriétés et les méthodes les plus utiles, héritées du modèle de base. Vous devrez créer vos propres méthodes pour réaliser toutes les requêtes SQL plus complexes !
/* App/Weblitzer/Model.php */
// Récupère une ligne de la table en fonction d'un identifiant
public function all()
public function findById($id)
public function findByColumn($column,$value)
public function delete($id)
Les vues ou templates permettent de séparer le code de présentation du reste de la logique (contrôleur) ou des données (modèles). On y retrouve donc essentiellement des balises HTML et des echo de variables PHP.
Donnée importante à connaître : Le framework vous impose de placer vos fichiers de vues sous le dossier view/app/. Outre cette règle, vous êtes libre de faire comme bon vous semble.
Ceci étant, la plupart des pages de votre application devrait avoir un fichier de vue propre. Ainsi, il devrait y avoir à peu près autant de routes que de méthodes de contrôleur que de fichiers de vue dans votre application. Il est donc important de les classer un minimum, afin de s'y retrouver. Pour cette raison, je vous suggère de placer vos fichiers de vue dans des répertoires portant le même nom que son contrôleur (sans le suffixe Controller, et en minuscule). Ainsi, si vous avez un PostController et un UserController dans votre application, vous devriez avoir un dossier de vues nommé view/app/post/ et un autre nommé view/app/user/. Ce n'est toutefois qu'une convention suggérée.
Les fichiers de vue doivent avoir l'extension .php.
Au plus simple, un fichier de vue ne doit contenir qu'une page HTML complète. Lorsque votre contrôleur déclenchera l'affichage de votre fichier de vue, il enverra le contenu de celui-ci en réponse au client.
Tous les fichiers publics de votre application (public dans le sens que vous considérez qu'un internaute doit pouvoir l'afficher directement dans son navigateur) doivent se trouver dans le dossier public/. Autrement, le navigateur n'y aura tout simplement pas accès. Ainsi, vos fichiers .css, .js et vos images (souvent nommés assets) devront nécessairement y être placés.
Création d'une application pour gèrer les emprunts de produits par des abonnés d'une association.
- **Abonnes** (id, nom, prenom, email, age (null), created_at)
- **Products** (id, titre, reference, description(textarea) )
- **Borrows** (id, id_abonne, id_product, date_start, date_end(null))
Faire un crud complet pour les abonnés et aussi les Produits. Faire une seule page qui va afficher tous les emprunts ainsi que le formulaire d'ajout qui contiendra deux select, un pour choisir parmi les abonnées et un autre pour sélectionnez le produit On pourra enlever un emprunt de la liste en donnant une date à date_endAfficher le nombre d'abonnés.
Afficher le nombre de produits.
Afficher le nombre d’emprunts total.
Afficher le nombre d’emprunts en cours.(date_end IS NULL)
- Gestion des catégories de produits.
- Pagination numérotée des listings des abonnés et des produits.
- Gestion d'un formulaire au choix à l'aide d'Ajax.