24
Nov/09
0

Mise en place de Mnesia dans mochiweb

Introduction

Les données de l’applicatif proviennent de plusieurs sources, et sont stockées différemment selon les besoins.

Par exemple, couchDB ne sera pas utilisé pour stocker les informations d’authentification des utilisateurs. Pour cela, on s’appuiera sur la base de données mnesia fournie avec erlang.

Lancement

La première action à faire est de modifier le fichier Rakefile.rb afin de démarrer le module mnesia au démarrage de l’application :

task :start => [ :build, 'env:start' ] do
  system "erl -pa #{EBIN_DIR} #{ROOT}/deps/*/ebin -boot start_sasl -s reloader -s inets -s app -mnesia dir 'db'"
end

Les fichiers de données seront stockés dans le répertoire indiqué dans la ligne de commande. Le répertoire sera créé au moment de l’initialisation de la base.

Initialisation

Il est nécessaire ensuite de créer la base elle même. On pourrait ajouter le code nécessaire au niveau de la fonction erlang de démarrage applicatif. Cependant, on va créer une tâche et une fonction spécifique à cette initialisation. Au démarrage de l’application, on suppose que la base est créée… sinon le système plantera.

Pour cela, on crée une tâche d’initialisation dans le fichier Rakefile.rb :

namespace 'db' do
  task :create do
    system "erl -pa #{EBIN_DIR} -s xxx_db create -mnesia dir 'db' -s init stop"
  end
end

On démarre la fonction create du module xxx_db, et les données seront stockées dans le même répertoire que vu précédemment.

Ce module est un fichier créé dans le répertoire des sources src/xxx_db.erl, et défini ainsi :

-module(xxx_db).
-export([create/0]).
-include("records.hrl"). (a)
 
create() ->
  mnesia:delete_schema([node()]),
  mnesia:create_schema([node()]), (b)
  mnesia:start(),
 
  mnesia:create_table(user, [{disc_copies, [node()]}, {attributes, record_info(fields, user)}]), (c)
 
  mnesia:stop().

Une base mnesia requiert un espace d’adressage qui comporte un certain nombre de propriétés. C’est ce qui est défini dans la création du schéma (b), ici les propriétés par défaut sont positionnées.

On démarre le moteur mnesia, et on créé les tables nécessaires (c) en suivant les définitions. Ces définitions sont introduites par une directive non vue encore (a) qui permet d’inclure des fichiers de définition. Ce fichier contient la définition des tables et se trouve dans le répertoire source src/records.hrl. Il a cette forme :

-record(user, {name, password}).

Les records sont une facilité d’écriture fournie par erlang et représentent des tuples nommés. Ce fichier sera inclus dans l’applicatif dès que l’on devra manipuler une table mnesia.

Important : mnesia considère que le premier champ du record représente sa clé ! Cette dernière pourra être utilisée pour une interrogation directe.

Note : De même, on peut créer la fonction init/0 qui pré-rempli la base avec des données de référence.

Intégration mochiweb

Mnesia doit être démarré comme tout autre service lors du lancement de notre applicatif. On modifie donc le fichier de démarrage src/xxx_app.erl afin d’intégrer ce comportement :

start(_Type, _StartArgs) ->
  application:start(crypto),
  application:start(mnesia),
  application:start(ecouch),
  xxx_deps:ensure(),
  xxx_sup:start_link().
 
stop(_State) ->
  application:stop(ecouch),
  application:stop(mnesia),
  application:stop(crypto),
  ok.

A partir de là, la base mnesia peut être interrogée par l’applicatif. Ces interrogations se font directement par les fonctions de l’API mnesia ou bien par le système qlc basé sur des expressions de listes.

16
Oct/09
0

Validation de formulaires en Erlang

Problématique

L’envoi des données de formulaire se fait par Ajax également.

Il est nécessaire de pouvoir sérialiser le formulaire afin d’envoyer les données sur le réseau, ainsi que de brancher le mécanisme côté serveur pour récupérer et valider les données.

Côté client, la sérialisation d’un formulaire se fait tout simplement en utilisant les mécanismes jQuery ; rien de spécial ici, on commencera par sérialiser un formulaire particulier avant de passer à une généralisation.

Côté serveur, nous allons mettre en oeuvre la récupération des données et leur validation. Tout ce qui vient du client doit être considéré comme non sûr et potentiellement corrompu.

La validation serveur est donc un processus absolument primordial. La pré-validation cliente est accessoire et ne sera pas traitée pour le moment.

Cette validation cliente participe à l’amélioration de l’expérience utilisateur. Pour notre part, avec l’architecture particulière mise en place où seuls les éléments mis à jour transitent entre le client et le serveur, on espère que la validation serveur ne sera pas trop pénalisante et donc suffisante dans un premier temps.

21
Jul/09
0

Mochiweb & CouchApp

Les auteurs de CouchDB définissent un ensemble de fonctionnalités afin de contenir l’ensemble des données et processus (logique métier / réponse aux événements utilisateurs) au sein d’un serveur CouchDB.

Cela permet de créer des applications complètes. Le passé de Damien Katz au sein de L’équipe de développement de Lotus n’est pas étranger à cet état de fait.

Le fait de stocker l’ensemble des éléments dans CouchDB permet une réplication automatique à la fois des données et des traitements, ce qui peut être extrêmement utile.

Malgré tout, je reste sur l’utilisation de Mochiweb pour l’ensemble des briques métier :

  • CouchApp n’est pas encore une technologie éprouvée,
  • Force l’utilisation des API couchDB (hum, problème du « vendor lock in »),
  • Ne correspond pas à ce que je désire faire avec ce projet
Filed under: Mochiweb
21
Jul/09
2

Installation et démarrage de Mochiweb

Afin de réaliser une application web, il est nécessaire d’obtenir et utiliser un serveur applicatif qui sera capable de fournir les services dynamiques.

Au niveau Erlang, le choix est vite cerné, et ce rôle sera dévolu à l’application Mochiweb.