Comprendre le fonctionnement de Stato
Convention over configuration
Stato repose en grande partie sur ce principe de “conventions, plutôt que configuration”, inspiré par RubyOnRails. L’intérêt majeur est de pouvoir écrire moins de code ! Stato se repose sur des conventions de nommage pour déduire les relations entre les divers composants de votre application. Par exemple, une action nommée view() dans un controller PostsController sera suivie du rendu d’un template nommé view.php dans le dossier app/views/posts (à moins que vous ne lui indiquiez explicitement de faire autre chose).
Le modèle MVC
Stato est un framework exploitant le modèle MVC : Model - View - Controller. Le MVC est un modèle de développement en 3 couches, créé initialement pour le langage SmallTalk dans les années 80. Il s’adapte parfaitement au développement web.
La couche model contient et modifie les données : elle définit les “Domain objects” (tels que User, Product, ...) ainsi que leurs relations entre eux. Elle définit également tous les traitements susceptibles de s’appliquer à ces objets, constituant ainsi la “Business logic”.
La couche view constitue l’affichage présenté à l’utilisateur : dans le cas d’une appli web, elle doit donc être capable de générer du HTML, du Javascript, etc. C’est le siège de la “Presentation logic”.
La couche controller fait le lien entre les models et les views : elle reçoit les requêtes de l’utilisateur, interagit avec les models pour modifier ou recupérer des données, et les envoie aux views pour affichage. Elle définit donc l’“Application logic”. En théorie, les couches model et view ne doivent rien savoir l’un de l’autre, ainsi vous pourrez, avec la même couche model, proposer une interface utilisateur totalement différente.
Le MVC dans Stato
Les models constituent donc le coeur du système : ils modélisent les objets de base que votre application doit manipuler. En général, les models sont indépendants du mode de stockage des données (DB, fichiers texte, XML...), mais dans le cas d’une application web où les données sont le plus souvent stockés dans une base de données, les models peuvent ne pas être totalement séparés de leur stockage. Pour répondre aux cas d’utilisation les plus fréquents, Stato propose la classe SActiveRecord, basée sur le design pattern du même nom. L’ActiveRecord est une forme simple d’ORM (object-relation mapping), où chaque objet correspond à un enregistrement d’une table, et sait gérer sa persistence.
Les views sont l’interface utilisateur de votre application. Dans Stato, les views sont générées à partir de templates mélangeant HTML et PHP. Des helpers (simples fonctions PHP) sont également à votre disposition pour générer des blocs de HTML. Le controller choisit la view à afficher, et lui fournit les données nécessaires.
Les controllers font donc le lien entre le model et la view. Un utilisateur clique par exemple sur un lien, indiquant son souhait de réaliser une certaine action. Stato va donc instancier le SActionController correspondant, et appeller l’action en question (en fait une méthode du controller). Cette action va interagir avec la couche model, soit en récupérant des données pour les fournir à une view, soit en modifiant les données pour ensuite rediriger vers une autre action (et donc une autre view).
