Flux d'application Ruby on Rails

Lorsque vous écrivez vos propres programmes du début à la fin, c'est facile à voir contrôle de flux. Le programme commence ici, il y a une boucle, les appels de méthode sont là, tout est visible. Mais dans une application Rails, les choses ne sont pas si simples. Avec un cadre de toute nature, vous abandonnez le contrôle de choses telles que le «flux» au profit d'une manière plus rapide ou plus simple de faire des tâches complexes. Dans le cas de Ruby on Rails, le contrôle de flux est entièrement géré dans les coulisses, et tout ce qui vous reste est (plus ou moins) une collection de modèles, de vues et de contrôleurs.

HTTP est au cœur de toute application Web. HTTP est le protocole réseau utilisé par votre navigateur Web pour parler à un serveur Web. C'est de là que viennent des termes comme «demande», «GET» et «POST», ils sont le vocabulaire de base de ce protocole. Cependant, puisque Rails est une abstraction de cela, nous ne passerons pas beaucoup de temps à en parler.

Lorsque vous ouvrez une page Web, cliquez sur un lien ou soumettez un formulaire dans un navigateur Web, le navigateur se connecte à un serveur Web via TCP / IP. Le navigateur envoie ensuite au serveur une «demande», pensez-y comme un formulaire de courrier électronique que le navigateur remplit en demandant des informations sur une certaine page. Le serveur envoie finalement au navigateur Web une «réponse». Ruby on Rails n'est cependant pas le serveur Web, le serveur Web peut être n'importe quoi de Webrick (ce qui se produit généralement lorsque vous démarrez un serveur Rails à partir de le

L'une des premières choses qu'une application Rails fait avec une requête est de l'envoyer via le routeur. Chaque demande a une URL, c'est ce qui apparaît dans la barre d'adresse d'un navigateur Web. Le routeur est ce qui détermine ce qui doit être fait avec cette URL, si l'URL a du sens et si l'URL contient des paramètres. Le routeur est configuré dans config / routes.rb.

Tout d'abord, sachez que le but ultime du routeur est de faire correspondre une URL avec un contrôleur et une action (plus sur ces derniers plus tard). Et puisque la plupart des applications Rails sont RESTful, et que les choses dans les applications RESTful sont représentées à l'aide de ressources, vous verrez des lignes comme ressources: messages dans les applications Rails typiques. Cela correspond aux URL comme /posts/7/edit avec le contrôleur Posts, le Éditer action sur la poste avec l'ID de 7. Le routeur décide simplement où vont les demandes. Notre bloc [Rails] peut donc être un peu développé.

Maintenant que le routeur a décidé à quel contrôleur envoyer la demande et à quelle action sur ce contrôleur, il l'envoie. Un contrôleur est un groupe d'actions connexes regroupées dans une classe. Par exemple, dans un blog, tout le code pour afficher, créer, mettre à jour et supprimer des articles de blog est regroupé dans un contrôleur appelé «Publier». Les actions sont tout simplement normales les méthodes de cette classe. Les contrôleurs sont situés dans application / contrôleurs.

Disons que le navigateur Web a envoyé une demande de /posts/42. Le routeur décide que cela fait référence à la Publier contrôleur, le spectacle et l'ID du message à afficher est 42, il appelle donc spectacle avec ce paramètre. le spectacle n'est pas responsable de l'utilisation du modèle pour récupérer les données et de l'utilisation de la vue pour créer la sortie. Donc, notre bloc étendu [Rails] est maintenant:

Le modèle est à la fois le plus simple à comprendre et le plus difficile à mettre en œuvre. Le modèle est responsable de l'interaction avec la base de données. La façon la plus simple de l'expliquer est que le modèle est un simple ensemble d'appels de méthode qui renvoient des objets Ruby simples qui gèrent toutes les interactions (lectures et écritures) de la base de données. Donc, en suivant l'exemple du blog, l'API que le contrôleur utilisera pour récupérer les données à l'aide du modèle ressemblera à quelque chose comme Post.find (paramètres [: id]). le params est ce que le routeur a analysé à partir de l'URL, Post est le modèle. Cela fait des requêtes SQL ou fait tout ce qui est nécessaire pour récupérer le billet de blog. Les modèles sont situés dans application / modèles.

Il est important de noter que toutes les actions n'ont pas besoin d'utiliser un modèle. L'interaction avec le modèle n'est requise que lorsque les données doivent être chargées à partir de la base de données ou enregistrées dans la base de données. En tant que tel, nous mettrons un point d'interrogation après dans notre petit organigramme.

Enfin, il est temps de commencer à générer du HTML. Le HTML n'est pas géré par le contrôleur lui-même, ni par le modèle. L'intérêt d'utiliser un framework MVC est de tout compartimenter. Les opérations de base de données restent dans le mode, la génération HTML reste dans la vue et le contrôleur (appelé par le routeur) les appelle tous les deux.

Le HTML est normalement généré à l'aide de Ruby intégré. Si vous êtes familier avec PHP, c'est-à-dire un fichier HTML avec du code PHP intégré, alors Ruby intégré sera très familier. Ces vues sont situées dans app / vues, et un contrôleur appellera l'un d'eux pour générer la sortie et la renvoyer au serveur Web. Toutes les données récupérées par le contrôleur utilisant le modèle seront généralement stockées dans un variable d'instance qui, grâce à un peu de magie Ruby, seront disponibles en tant que variables d'instance dans la vue. De plus, Ruby intégré n'a pas besoin de générer du HTML, il peut générer n'importe quel type de texte. Vous le verrez lors de la génération de XML pour RSS, JSON, etc.

Cette sortie est renvoyée au serveur Web, qui la renvoie au navigateur Web, qui termine le processus.