MyDMAM : les utilisateurs d’un DMAM

Cet article fait parti d’une série d’article de présentation d’un projet libre et expérimental que j’ai écris. Il va être question ici de l’interface entre les utilisateurs et MyDMAM.

Publié le

Vos médias, vos choix. Mais comment ? Aujourd’hui, on ne trouve pas plus simple comme interface graphique qu’un site web. Un client lourd, c’est complexe à écrire, c’est plus ou moins compatible suivant les plateformes, c’est lourd à maintenir, et ça vieillit très vite.

Un client mobile, ça demande un travail d’intégration qui peut être différent sur chaque plateforme. Il existe des technologies cross-plateforme, mais il faut encore attendre qu’elle murissent. Et elle ont aussi leurs limites.

Bref, un site web, c’est bien. Plutôt une application web. Responsive et dynamique. J’ai tenté l’approche « de base » Boostrap & jQuery, et après avoir écris un gros code bien lourd et gras (ce que je voulais éviter au départ), j’ai découvert React de Facebook. Une claque technologie qui propulse un développement web en quelque chose d’agréable. React permet de mélanger du templating/vue avec son contrôleur et son model, pour chaque élément de la page. Et surtout, toute la structure est éclaté en composants autonomes, structurés et réutilisables.

Pourquoi tant de contrainte ? L’accès utilisateur se doit être rapide (il ne doit pas attendre un chargement) et asynchrone (quand il doit attendre, il doit pouvoir faire quelque chose d’autre en attendant). Car si l’interface utilisateur destinée à être un outil de travail ; et c’est le but ; autant que celle si soit agréable et pratique. Ecrire un outil pénible à utiliser n’a aucun intérêt. Et pourtant, c’est ce que la facilité amène, si l’on ne prends pas le temps de penser comment l’outil doit être utilisé, plus que comment il doit être fait.

Le travail de développement doit être lui aussi léger. Ajouter ou changer un élément au niveau utilisateur, voir même refondre tout le site doit être tout le temps envisageable. Un développement web lourd est condamné à pourrir la vie des utilisateurs avec le temps car les besoins et les exigences évoluent naturellement au cours du temps ; le code lui ne se changera pas tout seul. Et si la modification d’un élément demande de comprendre la totalité autour, alors rien ne changera a cause de cette inertie. La vision du DMAM que les utilisateurs auront sera comme une technologie pétrifiée.

La technologie du serveur web est Play! Framework, v1 (la v2 est arrivée trop récemment et la bascule demande de retirer et de réadapter trop de code hérité ; ça sera pour plus tard). L’approche modulaire, Rails like (MVC « tout seul », si on respecte les noms et leurs emplacements), script like (on change un fichier, et il se compile tout seul, comme du PHP), qui permet à du Java d’être très souple pour du développement web. Les approches Tomcat ou Java EE semblent tellement vielles et lourdes à coté.

Rien dans MyDMAM impose formellement Play ou Java. MyDMAM est écrit en Java et utilise Play, mais du moment où les données sont aux bons endroits dans les bases, ça marchera avec d’autres langages/développements. La cohabitation est toujours possible car il n’y a pas de sérialisation binaire ni de magie vaudou sur les bases (pas d’ORM systématique avec d’obscures requêtes internes ni de schémas imposés).

Un utilisateur peut être un robot. Pour être plus précis on doit pouvoir envisager d’accéder à une fonction du site utilisateur via… un script. Et l’on n’a pas toujours envie d’attaquer la base pour « juste » remonter une info. C’est parfois plus pratique d’avoir des données déjà traités/filtrés/organisées par le code existant plutôt que de devoir le faire coté script.

Ici, une très grande partie des infos, notamment toutes celles remontées par React le sont via une forme d’API REST en Json qui se veut le plus simple possible. Il y a encore un grand travail à faire pour avoir une vrai API, notamment pour inclure une authentification de script (type Oauth), mais l’approche coté serveur est déjà là.

Quitte à fournir une API et un site utilisateur, autant que le site utilisateur repose nativement sur cette API. C’est vers cette orientation que sont dirigés les développements web, actuellement, ce n’est pas encore le cas.

A propos d’authentification utilisateur, MyDMAM utilise accès login via une base SQLite local et via un LDAP pré-configuré pour Active Directory. L’approche est assez candide, mais ça marche très bien. On peut cumuler autant de configurations SQLite/LDAP que l’on veut afin de garder cet esprit très modulaire pour avoir plusieurs sources d’authentification.

L’authentification elle-même est couplée à un module simple de gestion utilisateur (on peut stocker des données tierces dans Cassandra pour chaque utilisateur, comme ses paniers de sélection de médias) et à un système d’ACL qui est lui aussi simple. On peut lier un utilisateur à un groupe, et lier un groupe à un rôle auquel on définit des privilèges. Ces privilèges sont des fonctionnalités du site. Un utilisateur qui se connecte sans privilèges pourra juste… se déconnecter. Comme on peut définir des privilèges par défaut pour les nouveaux utilisateurs, l’administrateur peut leur laisser librement l’accès, à partir du moment ou ils peuvent se logguer via un annuaire, sans à avoir préalablement besoin de paramétrer tous les droits à l’avance.

La suite : MyDMAM : l’installation d’un DMAM