23
Jul/09
0

Pure IHM

Le système final est prévu comme étant une « application web ».

Je fais la distinction entre « application web » et « site web » : ce dernier étant soumis aux contraintes habituelles des sites internet, à savoir principalement les questions d’accessibilité et d’indexation (référencement, SEO).

Ces questions ne seront pas prises en compte ici, une application web étant une application riche dont le déploiement se déroule à travers Internet. A cette fin, plusieurs technos sont disponibles dont celles d’Adobe avec Flex, Microsoft avec .NET ou Silverlight.

Le challenge est de rester en technologies W3C le plus possible.

Le but est donc de mettre en place les composants qui seront dédiés à l’interface utilisateur.

Architecture

Le système est donc composé des éléments suivants :

Base de données
Rôle dévolu à CouchDB, et éventuellement Mnesia.
Serveur applicatif
Mochiweb sera le serveur utilisé. Son unique rôle sera de servir les flux de données au format JSON principalement. Il réagira également aux actions utilisateurs postées en tant que requêtes Ajax. Le serveur applicatif ne traitera/fournira que des données, aucune manipulation de code HTML ne devra être effectuée.
Serveur web
Nginx est un candidat potentiel.
Serveur de cache
Squid pourra être ajouté afin d’augmenter les performances applicatives. Il est prévu que de nombreuses requêtes transitent entre le client et le serveur (pas de problématique réelle de production à ce niveau là).
Client
Le navigateur sera le seul client implémenté pour le système.

L’ensemble des traitements liés à l’interface aura donc lieu au niveau du navigateur, il est donc essentiel d’utiliser des composants javascript efficaces.

Interface

Pages

Toutes les actions auront lieu au niveau du navigateur. Pour l’instant cela implique qu’une seule page HTML sera générée au niveau serveur (priv/www/index.html). Elle aura l’organisation suivante :

<!DOCTYPE>
<html>
	<head>
		<title>Ercm</title>
	</head>
	<body>
		<div id="templates">
			<div class="block">
				<h2 class="title"></h2>
				<div class="content"></div>
				<div class="actions"></div>
			</div>
		</div>
		<div id="main"></div>
	</body>
</html>
Notes
Le système mis en place s’inspire fortement de ce qui est montré par les développeurs de la start-up Beebole, donc on retrouvera ici des éléments très similaires. A noter que tout le code produit sera entièrement de mon fait.
L’interface est pour l’instant réduite à son strict minimum, elle sera améliorée ultérieurement.

L’accès par navigateur affichera une page blanche.

Deux blocs sont définis, un premier bloc contiendra les modèles HTML à utiliser pour affichage, le second (main) contiendra le code JSON transformé.

Le projet sera augmenté des répertoires suivants :

priv/
  www/
    assets/
      scripts/
      images/
      styles/

Remarques :

  • On crée un répertoire assets pour toutes les ressources statiques, afin de les regrouper en une seule URI, ce qui permet ensuite de les référencer facilement (par exemple au niveau du serveur web),
  • on utilise des noms sémantiquement corrects plutôt que des noms techniques : par exemple scripts plutôt que javascript.

Scripting

Le choix technique des bibliothèques javascript se porte sur Pure, avec le support de jQuery.

Ces bibliothèques sont incluses en fin de page - juste avant le tag </body> afin de satisfaire les règles YSlow sur les performances.

Les blibliothèques seront ajoutées en mode développement (aucune compression) ; le fait d’utiliser ruby et rake nous permettra d’ajouter ensuite des processus qui compileront et fusionneront les fichiers afin de limiter les requêtes de téléchargement.

Le code sera augmenté de la manière suivante :

	<div id="main"></div>
	<script type="text/javascript" src="/assets/scripts/jquery-1.3.2.js"></script>
	<script type="text/javascript" src="/assets/scripts/pure-2.08.js"></script>
</body>

Exemple

Pour tester la partie dynamique, on procède en deux étapes :

  • création du service permettant de fournir les données JSON,
  • appel du service et utilisation des données au niveau de la page

Le service web sera écrit en dur, en modifiant le fichier src/ercm_web.erl de la manière suivante :

    case Req:get(method) of
        Method when Method =:= 'GET'; Method =:= 'HEAD' ->
            case Path of
                "test" ->
			Req:ok({"application/json", [], ["{title:'Test',content:'Data loaded from server'}"]});

Ce service réagit à l’url http://localhost:8000/test et renvoi un code 200 dont les données sont de type JSON.

ecr01

Pour l’utiliser, on relance une compilation avec la commande rake. La console du serveur (qui a été démarré avec rake start) indique que le module est rechargé :

Reloading ercm_web ... ok

Au niveau navigateur, on procédera comme suit :

<script type="text/javascript">
	$(function() {
		$.getJSON("/test", function(context) {
			$("#templates .block").autoRender(context);
		});;
	});
</script>

L’écran affiche ceci :

ecr02

On utilise ici la capacité d’auto-synchronisation (! pas très français, je sais) de Pure : la bibliothèque prend alors chaque entrée JSON et essaie de la faire correspondre à une classe du graphe DOM indiqué comme cible. C’est pourquoi il était nécessaire de mettre une classe « titre » au niveau du tag h2 même si d’un point de vue sémantique ce n’est pas terrible.

Avec un peu d’efforts de styles, on peut arriver à ceci :

ecr03

Sources

Les sources sont disponibles à cette adresse : http://github.com/rv/ercm/tree/blog01

Conclusion

Pour conclure, faisons remarquer que la synchronisation de Pure n’est qu’unidirectionnelle, et les modifications apportées à des objets du DOM doivent être récupérées de façon manuelle par javascript.

Il existe aujourd’hui des composants extrêmement avancés côté navigateur permettant un développement efficace d’interface cliente.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.