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.

6
Oct/09
0

Mise en oeuvre de l’authentification (3 - niveau navigateur)

On met en oeuvre la partie utilisateur/interface.

Tout d’abord, on rajoute un lien dans l’en-tête du site afin de diriger sur l’url /login.html (priv/templates/views/index.haml) :

  %body
    #header
      #ids
        Guest
        %a{ 'data-event' => "login:start", :href => "/login.html" } (login)

Ce lien possède un attribut particulier data-event. Cet attribut est correct selon les normes HTML 5, et peut être utilisé sans problème dès aujourdh’ui. Pour plus d’informations, vous pouvez lire cet article de John Resig.

Cet attribut personnalisé va nous permettre de définir des liens demandant un déclenchement d’événement lors d’un click. Cet événement est la valeur de l’attribut lui même. Le comportement générique sera de ne pas déclencher le click normal (navigateur) mais de le remplacer par le déclenchement de l’événement.

2
Oct/09
0

Vim et Rake

La structure de notre projet implique des phases de pré-processing permettant soit de compiler des sources en binaires, soit de transformer des modèles de vues en fichiers cibles.

Ces actions sont réalisées via le gestionnaire de tâches rake. Ces actions sont effectuées pour l’instant en ligne de commandes. Par exemple :

$ rake -T
rake build      # Build the sources
rake clean      # Clean workspace
rake compile    # Compile the sources
rake db:create  # Initialise a database
rake edoc       # Create documentation
rake front      # Preprocess views and styles
rake release    # Packaging
rake start      # Start application
rake test       # Unit tests
 
$ rake front
Creating style /d/apps/gns/priv/www/assets/styles/application.css
 
$

Nous allons intégrer ces commandes au sein de Vim afin de simplifier le processus (ne pas avoir à jongler entre les fenêtres) et l’automatiser (ne rien oublier afin de ne pas s’énerver parce que ça ne marche pas !).

2
Oct/09
0

Gestion générique des appels Ajax

Le fonctionnement au niveau du navigateur est revu, et on pose les briques de base pour une gestion générique des événements Ajax au niveau de l’interface.

Pour cela, jQuery offre de nombreux points de rattachement lorsqu’une requête Ajax est déclenchée.

Notre but sera de programmer des comportements génériques de la façon la plus personnalisable et en essayant de rester au plus près du style de programmation jQuery.

28
Sep/09
0

Mise en oeuvre de l’authentification (2 - niveau serveur)

L’article précédent a défini la façon dont le code utilisateur sera stocké dans au niveau du poste client, à savoir dans un cookie dont l’altération ne sera pas possible.

Maintenant, il est nécessaire de pouvoir mettre en oeuvre cette formulation au sein de l’application. Cette dernière sera principalement privée.

25
Sep/09
0

Automatisation des microtests Erlang via Rake

Les fonctions de tests unitaires commencent à apparaitre dans plusieurs fichiers, et il devient nécessaire de pouvoir régulièrement rejouer l’ensemble de ces tests. Ceci ne pouvant se faire que de manière automatique pour être efficace.

Attention on rappelle qu’il ne s’agit ici que de vérifier simplement et rapidement des comportements écrits directement dans les fichiers sources. Il est évident que pour des opérations plus complexes, un réel outil de tests unitaires tel que eUnit devra être mis en place.

Pour cela, on va réutiliser ce que l’on a déjà mis en place précédemment concernant l’exécution de la machine virtuelle Erlang via Rake (voir posts précédents).

Le but est de parcourir l’ensemble des fichiers sources .erl et déterminer pour chacun d’eux si une fonction tes/0 a été définie, auquel cas on exécute la méthode du module en question.

L’analyse du fichier sera une bête expression régulière, et pour cela on patch la classe File de Ruby afin de conserver une certaine harmonie dans l’écriture :

class File
  def self.contains?(filename, regexp)
    text = File.read filename
    return text.match(regexp) != nil
  end
end

Pas très efficace comme programmation mais nous ne sommes concernés que par des fichiers sources qui sont, par définition, des fichiers textes de petite taille.

On crée alors une tâche Rake :

desc "Unit tests"
task :test => :compile do
  sources.each do |source|
    if File.contains? source, /^test\(\) ->$/
      mod = File.basename(source, ".erl")
      puts "Unit testing #{mod}"
      system "erl -pa #{EBIN_DIR} #{ROOT}/deps/*/ebin -noshell -noinput -s inets -s crypto -s #{mod} test -s init stop"
    end
  end
end

Cette tâche dépend de la compilation afin de pouvoir jouer les fonctions.

On a repris la commande système utilisée pour lancer l’application. Certains paramètres ont été ajoutés :

-noshell -noinput # Exécution en mode console non interactive
-s inets -s crypto # Démarrage de modules nécessaires, ici crypto est lié aux cookies
-s #{mod} test # Exécution de la fonction test() du module mod
-s init stop # Arrêt de la machine virtuelle
22
Sep/09
0

Cookies d’authentification

Comme quasiment toute application web, il est nécessaire d’identifier l’utilisateur afin de proposer des traitements et parties de site spécifiques pour cet utilisateur (zones privées, profilage, etc.).

La tendance actuelle, concernant notamment la possibilité de mise à l’échelle ultérieure, est de stocker les éléments de fonctionnement liés à l’utilisateur (données d’état à conserver entre plusieurs requêtes) à l’intérieur de cookie.

Ce mode de fonctionnement permet de s’approcher d’une architecture de type Shared Nothing (SNA), ce qui est une des architectures les plus efficaces. Cela permet également de ne pas introduire d’entrée de jeu des mécanismes (sessions) qui sont fortement structurants et limitatifs.

Le problème de cette solution est la transition des informations complètes (et pas seulement un identifiant de session) sur le réseau et leur utilisation au niveau du poste client. Le protocol SSL étant consommateur et ne pouvant pas être utilisé sur l’ensemble d’un site, cela suppose de bloquer toute manipulation des données par un client.

18
Sep/09
0

Calcul de distances et tests unitaires

Le système nécessite un calcul de distances approximatif entre 2 points. Pour cela, on récupère le calcul théorique sur internet (par exemple, ici).

La transformation en distance est une reprise tel que des algorithmes :

distance(Coord1, Coord2) ->
  {Lat1, Lon1} = Coord1,
  {Lat2, Lon2} = Coord2,
  AngularDist = math:acos(
                 math:sin(Lat1 * math:pi() / 180) * math:sin(Lat2 * math:pi() / 180) +
                 math:cos(Lat1 * math:pi() / 180) * math:cos(Lat2 * math:pi() / 180) *
                 math:cos((Lon2 - Lon1) * math:pi() / 180)),
  AngularDist * 6371. %% km

Les coordonnées sont passées pour l’instant sous la forme d’un tuple comprenand la latitude et la longitude.

18
Sep/09
0

Accès des Google Charts via Erlang

Le système utilise fortement la représentation visuelle des données sous forme de graphes. Pour cela, le plus efficace reste de capitaliser sur les services déjà disponibles et notamment l’API Google chart.

Le système de création de graphe par requêtage d’URL est simple mais reste compliqué à maitriser à cause de la notation utilisée et des nombreux paramètres disponibles.

Il devient nécessaire de fournir à l’application cliente une abstraction suffisante afin de réaliser plus rapidement les graphiques nécessaires.

10
Sep/09
0

Changement de direction

La cible de mes essais Erlang change, et les sources ne sont plus accessibles.

J’essaierai cependant de publier d’autres articles le long du développement. Pas sûr que j’y arrive