Journal de Dev #01 - Contao Locations
Les articles sur les retours d’expérience en matière de développement informatique ont pour vocation de mettre en évidence les problématiques et contraintes qui entourent notre quotidien de développeurs. Ce qui veut dire que nous n’allons pas expliquer en détail tous les concepts techniques utilisés. Seulement ce qui est nécessaire au déroulement de l’article.
Si toutefois, les concepts évoqués attirent votre attention, n’hésitez pas à nous solliciter pour en apprendre davantage ! :)
Pour ce premier article, nous allons prendre un sujet qui touche un peu à tout. L’objectif de ce module est d’afficher une carte sur une page, et de pouvoir y placer autant de marqueurs que l’on souhaite.
Dans cette première version, nous souhaitons ajouter quelques fonctionnalités basiques. Il est donc possible de choisir le type de carte parmi les 3 suivants : Google Maps, Leaflet & JVector. On peut également importer ou exporter un fichier Excel pour accélérer l’intégration des marqueurs.
Problématiques & Enjeux
Faire de la cartographie, ça semble simple quand on utilise Google Maps. Mais c’est une véritable usine à gaz derrière. Historiquement, chaque pays a utilisé sa propre nomenclature pour élaborer des adresses postales, sans vraiment se soucier de ce qu’à fait son voisin.
On retrouve des points communs, comme les codes postaux, mais bien souvent les niveaux administratifs et utilisations sont différents, et il faut deviner les similitudes. Quand c’est un voisin, c’est à peu près pareil, mais quand vous regardez une adresse à Shanghai ou à Abu Dhabi, c’est plus délicat de deviner.
Pour placer une adresse sur une carte, on ne se base pas sur l’adresse directement. Chaque adresse répond à des coordonnées spatiales : la longitude et la latitude. Ce sont des nombres, négatifs ou positifs, qui sont extrêmement précis. Pour les obtenir, on fait appelle au géocoding (on en parle plus bas).
Notre problématique majeure est donc d’obtenir les coordonnées les plus fiables possibles pour toutes vos adresses, peu importe leur pays. Et cela de la façon la plus pratique possible pour l’administrateur.
Le module est pensé dans ce sens car il est bien plus probable que vous ayez des adresses postales que des coordonnées.
Si toutefois, vous partez de coordonnées, et souhaitez obtenir des adresses “humainement lisibles”, il faut utiliser du “reverse geocoding” pour géocoding inversé. Oui je sais, logique comme nom.
Enfin, nous souhaitons donner le plus de configuration possible pour les cartes. Que ce soit dans le choix de la carte, les couleurs etc. Selon la librairie utilisée, ces possibilités seront plus ou moins étendues ou complexes à mettre en place, l’essentiel étant de maintenir une bonne ergonomie.
Le Backend
Conformément à notre volonté de rendre tous nos utilisateurs le plus indépendant possible, le backend doit permettre la totale administration du module.
Il ne contient que deux tables : tl_wem_map et tl_wem_location. On peut créer autant de cartes que l’on veut, et mettre autant d’emplacements que l’on veut dans une carte. La seule limite étant la lisibilité sur la carte.
Cartes
Dans chaque carte, on peut sélectionner la librairie que l’on veut utiliser. Aujourd’hui, on a accès à 3 librairies :
- Google Maps - La plus connue, mais plus si gratuite que ça
- Leaflet - Basée sur OpenStreetMap
- JVector - Représentation abstraite du monde, sous forme de polygones
Pour chaque librairie, on doit pouvoir sélectionner des options de configuration, ainsi que les éventuelles clefs API, pour Google notamment. Ayant récemment intégré Leaflet, grâce à une contribution github, nous n’avons pas encore rajouter les différents options de cette librairie.
Emplacements
Pour chaque emplacement, nous avons opté pour un nombre de champs essentiels et utiles à afficher dans une carte, notamment pour des clients francophones.
Nous retrouvons donc la longitude et la latitude, mais également un intitulé, une adresse postale, un numéro de téléphone, un email et un site internet. Nous avons également une case à cocher pour publier l’élément sur la carte, champ classique pour Contao.
Rien de très poussé ou compliqué, comme on l’a dit, l’objectif dans un premier temps est d’être très pragmatique dans la gestion du module et donc de ne pas le complexifier outre mesure.
Geocoding
Une des fonctionnalités importantes que nous avons intégré directement est le géocoding directement intégré dans le backend.
Mentionné précédemment, le géocoding permet d’obtenir les coordonnées spatiales d’un emplacement, uniquement en connaissant son adresse.
Nous avons intégré deux services permettant de le faire, Google Geocoding et Nominatim. Le service de Google est efficace, mais désormais payant, tandis que celui de Nominatim reste gratuit, mais le résultat n’est jamais garanti.
Une fois configuré dans la carte, il est désormais possible de géocoder toutes les adresses, celles sans coordonnées sont mises en évidence (ligne en rouge) dans le backend.
Les coordonnées sont alors sauvegardés en base de donnée locale, pour améliorer la performance de la carte et d’éviter les multiples appels au service de géocoding et d’indésirables conséquences (factures ou blacklisting...).
Import / Export
De même, dès la V1, nous avons intégré l’import / export via un fichier Excel. Cela nécessite d’avoir comme dépendance PHPSpreadsheet (anciennement PHPExcel).
On aurait pu se contenter d’un import / export de CSV, mais l’encodage est constamment foireux et foiré par la moitié des développeurs et des administrateurs du site.
L’objectif est d’aller plus vite, pas de galérer sur un autre logiciel que le CMS.
Bien conscient qu’il peut y avoir un existant, il est du coup possible d’indiquer au système ce qu’il doit attendre du fichier Excel. Via la carte, vous pouvez indiquer quelle colonne de la base de données correspond aux colonnes de votre fichier Excel.
Cela donne la souplesse nécessaire au système pour gérer toutes les saisies actuelles et permet d’anticiper toutes celles qui viendront dans le futur.
Intégration du module
Rien de spécial de ce côté là, puisque toute la configuration est intégrée dans la carte, vous pouvez soit créer un module Contao de type “Carte & Emplacements” ou bien un élément de contenu nommé de la même façon, et sélectionner ensuite la carte à afficher.
Le Frontend
Maintenant que les possibilités du backend ont été expliquées, voyons quel est leur impact en frontend.
Le module ne dispose pas encore de beaucoup de fonctionnalités, on l’a dit plus haut. L’essentiel est d’afficher des marqueurs sur la carte.
Les emplacements qui vont être récupérés seront ceux disposant de coordonnées spatiales correctement renseignées, et qui sont publiés. La carte sera si possible redimensionnée pour zoomer au plus proche des marqueurs disponibles.
Le nom du pays sera traduit selon la langue courante de l’utilisateur qui affichera la carte. Le reste étant très spécifique à chaque pays, nous n’avons pas encore ajouté de possibilités de traductions pour les intitulés ou adresses.
La librairie demandée sera correctement affichée, et sera chargée avec les options configurées et son design de marqueur par défaut.
Pour anticiper l’intégration de futures librairies, une structure explicite a été créée au sein du module. Une classe “ClassLoader” permet de renseigner les fichiers à charger selon la configuration d’une carte, et gère les différentes conditions ou erreurs qui peuvent survenir à ce moment. Comme une absence de clef API par exemple.
Il est prévu d’utiliser des interfaces PHP pour mieux encadrer les fichiers “Provider”, qui doivent contenir des fonctions et des traitements spécifiques, attendus par le frontend et le backend.
Plus d’informations sur les interfaces PHP à cette adresse : https://secure.php.net/manual/fr/language.oop5.interfaces.php
Limitations du module
Aujourd’hui, le module ne semble pas faire des choses évidentes, comme la gestion de champs particuliers, ou bien d’un design sur-mesure.
Il est très difficile d’anticiper quel sera le besoin global pour un tel type de module. Si les champs définis sont ceux qui sont essentiels, il est bien possible que pour un projet, il faudra rajouter un champ qui le sera tout autant. Ce qui veut dire qu’il faudra tout repenser pour intégrer ce nouveau champ.
Ensuite, les différences entre charte graphique font qu’il n’est utile que de personnaliser le marqueur, car la carte par défaut convient très souvent, et permet aux visiteurs du site de naviguer en terrain connu.
Dès lors qu’il faut personnaliser les couleurs de la carte, c’est souvent plus facile de le faire au cas par cas que de programmer des options.
Aujourd’hui, entre toutes les APIs de Google autour des cartes, il existe une bonne tripotée d’options, qui sont modifiées régulièrement - normal, ils mettent à jour leurs outils aussi.
Cela implique une lourde maintenance de notre côté, et le temps gagné ne serait pas si significatif que ça.
Il est préférable de savoir s’adapter que d’essayer de palier à tous les problèmes présents et futurs quand on travaille avec des APIs externes
Evolutions prévues
Pour ce module, l’essentiel était de prévoir une base relativement fiable pour permettre des évolutions diverses et variées que ce soit des fonctionnalités, optimisations ou l’intégration de nouvelles librairies ou services.
Gestion des champs d’emplacements spécifiques
Comme on l’a mentionné, aujourd’hui, les champs des emplacements sont fixes, mais on a souvent besoin d’en rajouter.
Ce pourquoi nous allons rajouter un systèmes d’attributs d’emplacements, qui seront configurables pour chaque carte, et qui devront être renseignés dans chaque emplacement.
Les champs actuels resteront à priori fixes, car ils restent essentiels pour garantir la cohérence du module.
Ajout de filtres sur la carte
Associés avec les les champs spécifiques, cette évolution prévoit d’autoriser le visiteur à filtrer les marqueurs sur la carte à l’aide de listes déroulantes, remplies automatiquement selon les données disponibles.
La carte sera actualisée et redimensionnée en fonction des marqueurs filtrés.
Ajout d’une liste des marqueurs juxtaposée à la carte
Tout simplement pour améliorer l’accessibilité au contenu, une liste des emplacements présents sur la carte, affichant les données disponibles.
La fonctionnalité est déjà présente sur JVector, mais elle nécessite une intervention graphique à chaque fois.
Ajout d’un accès à une page de contenus
Tous les emplacements ne disposent pas d’un site fournissant plus d’informations au visiteur. Ce pourquoi nous prévoyons d’ajouter un accès à une page de contenu additionnelle, soit via une nouvelle page ou une lightbox et autorisant l’administrateur à écrire davantage d’informations en étant un peu plus libre dans l’aspect de ce contenu.
Ajout d’une option marqueur
Très explicite, cette option permettra de personnaliser le marqueur général d’une carte. L’option sera également disponible pour chaque emplacement, et éventuellement pour les attributs, permettant ainsi de catégoriser visuellement les emplacements.
Voilà, le moment où tout cela sera ajouté, le module passera en version 1.0 !
Il reste encore un paquet de choses à faire, l’idée étant d’étendre le module sans devoir tout changer à chaque fois, pour garantir la compatibilité entre les différentes versions. Tout cela passe par une donnée fiable à la base, ce pourquoi nous nous attardons sur ce travail de fond plutôt que de forme dans un premier temps.
Le module est d’ors et déjà installable sur les Contao 4 disposant du Contao Manager, via Packagist.
Liens / Ressources
- Accès à la démo Frontend : https://demo.smartgear.webexmachina.fr/maps.html
- Accès au Github : https://github.com/webexmachina/contao-locations
- Accès à la doc Google Maps : https://developers.google.com/maps/documentation/?hl=fr
- Accès à Leaflet : https://leafletjs.com/
- Accès à JVector : http://jvectormap.com/
Dans la même catégorie
