Jul/090
Modules et contrôleurs
Erlang est un langage qui permet de créer et maintenir des applications complexes et volumineuses (en lignes de code). Pour ce faire, il est donc important de pouvoir découper de façon logique les programmes.
Ici, on utilisera la notion de modules. Rien d’extraordinaire en l’occurrence.
Séparation des responsabilités
Le principe en général est de diviser pour mieux régner. Une classe/module/process devant gérer plusieurs aspects différents sera anormalement complexe et deviendra dure à maitriser et maintenir.
On stockera toutes les petites fonctions utiles par rapport aux requêtes dans leur propre module.
On crée un fichier ercm_ctx.erl dans src qui exporte les deux fonctions définies dans l’article précédent :
-module(ercm_ctx). -export([init_accept/0, decode/1]). init_accept() -> ... decode(Req) -> ...
Et on les utilise dans ercm_web.erl :
{ok, Params, _} = ercm_ctx:decode(Req),
Puis on recompile le projet :
rake compile
Le problème est que ces modules doivent être déclarés dans le fichier de description de l’applicatif. Le but ultérieur sera de générer dynamiquement le fichier applicatif.
Actuellement, la mise à jour de l’application fonctionne quand même car on ne fait que modifier des fonctions au sein des différents modules, donc la mise à jour n’est pas destructive : il n’y a pas de conservation d’état.
Contrôleurs
Comme ce qui se fait ailleurs, il serait avantageux de pouvoir stocker les contrôleurs (oups) dans leur propre fichier / module.
-module(ctrl_test). -export([handle_http/3]). handle_http(Req, {'GET', json}, _) -> ercm_ctx:return_json_data(Req, "{title:'Test',content:'Data loaded from server'}").
De la même façon on l’appelle depuis ercm_web.erl.
case Path of "test" -> ctrl_test:handle_http(Req, Params, Data);
Notre but n’est pas de recréer un framework générique, ou de gérer dynamiquement des associations de routage entre URL et contrôleurs (méta-programmation).
Donc, le fait d’associer directement et explicitement le contexte de l’URL à une fonction d’un contrôleur n’est pas choquante. KISS et YAGNI doivent rester en permanence en mémoire.
Les routages imbriqués (ex: articles/$id/comments) seront donc gérés de la même manière, de façon explicite.
Comme pour le reste, si un routage manque, on rajoute sa fonction dans le module adéquat, on réalise l’association dans ercm_web.erl, on recompile… et le système est correctement mis à jour.
Sources : http://github.com/rv/ercm/tree/blog03.
