Introduction

La contrainte principale de ce projet réalisé pour le compte du CAUE Dordogne était la possibilité pour le client d'éditer la plupart des contenus du site. Cependant, la partie centrale de l'application étant la partie web mapping, nous ne souhaitions pas déployer l'architecture de l'un des CMS que nous maitrisons (Plone ou Drupal).

A l'instar d'autres projets Makina Corpus, notre choix s'est porté sur le générateur de sites statiques Jekyll, qui possède les avantages suivants :

• installation simple et rapide sur un poste de développement (bien qu'en ruby, qui n'est pas forcément notre technologie de prédilection chez Makina Corpus) ;
• couplage natif avec l'hébergement GitHub Pages (hébergement garanti, efficace, sans surcoût d'installation supporté par le projet), et donc, aucun serveur de production à installer ;
• édition des contenus possible via un éditeur de texte riche grâce au client web Prose.io (qui possède une interaction native avec les dépôts GitHub).

Architecture

Nous avons démarré le projet par une définition complète de l'architecture du projet (pour nous permettre de rapidement mettre au point une application prototype traversant les couches et validant la faisabilité technique).

Une application de web mapping est principalement composée de 3 éléments : le fond de carte, les couches de données, l'application en elle-même (les évènements sur les couches).

TileMill

Principalement développé par MapBox, TileMill permet de réaliser des fonds de cartes directement à partir de fichier géographiques de divers formats, avec un contrôle total du rendu par une syntaxe pseudo-CSS (adaptée aux développeurs web que nous sommes, mais facilement lisible par des non-techniciens si besoin). Les tuiles du fond de carte, une fois créées et exportées au format MBTiles, seront servis par notre serveur de tuiles, propulsé par django-mbtiles.

Leaflet

Notre bibliothèque de web mapping favorite est actuellement Leaflet, projet dynamique, doté d'une API simple que nous maîtrisons. Leaflet affichera non seulement les tuiles décrites ci-dessus, mais également des couches de données. Il aurait été possible d'ajouter quelques évènements sur la carte directement dans TileMill, mais pour permettre un contrôle poussé du contenu au client, nous nous sommes orientés vers un chargement dynamique de fichiers GeoJSON (avec éventuellement en tête de permettre une modification des fichiers par http://geojson.io).

Jekyll

La page principale de notre application sera donc une page Jekyll comportant une carte gérée par Leaflet.

Les contenus "non-cartographiques" (texte & photos) seront également gérés par Jekyll (pour permettre la modification via Prose.io), et demandés dynamiquement par Leaflet en fonction des actions des visiteurs sur la carte.

Configuration de base

Jekyll

L'hébergement GitHub Pages impose le paramètre suivant pour la configuration Jekyll (dans le fichier _config.yml) :

safe: true

(qui désactive tous les plugins Jekyll). Nous utilisons donc ce paramètre également en développement pour nous assurer de la compatibilité de nos applications avec GitHub Pages, environnement cible en production. De plus, nous ajoutons à la configuration la liste de fichiers que nous ne souhaitons pas voir générés dans le site :

exclude:
  - README.md
  - .gitignore

Ceci nous permet de commenter tout de même notre repository GitHub de façon standard, sans générer de fichier additionnel dans la version servie par GitHub Pages.

Notre site Jekyll comporte également de façon standard :

• un dossier "_layout", permettant de définir des mises en pages différentes selon les contenus (dans notre cas : la page par défaut qui servira la carte, et une page utilisée pour les contenus affichés en popup) ;
• un dossier "_includes", permettant de réutiliser des élements de code entre les différentes mises en page ;
• tous les autres fichiers courants pour une application web mapping (fichiers css, js, …).

Prose.io

Prose.io permet d'éditer n'importe quel fichier du site en utilisant un éditeur riche. Pour restreindre les actions possibles par le client, et lui permettre ainsi un contrôle total du contenu sans risque de casser l'application, nous organisons volontairement notre application en regroupant tous les "contenus" du site dans un sous-répertoire "data", seul accessible par Prose.io (toujours dans le fichier _config.yml de Jekyll) :

prose:
  media: "data/images"
  rooturl: "data"

(le répertoire media indique à Prose dans quel répertoire sont stockées les images, permettant aux clients d'insérer via l'éditeur les images stockées dans le dépôt).

Conclusion

Nous avons brièvement présenté l'architecture et la configuration technique du projet, nous étudierons dans la suite des articles le développement concret de l'application au travers de quelques exemples de code.