Interface de django_hg
Bien que je n’ai pas posté de message, je ne suis pas resté inactif ses derniers jours. Je travaille sur l’interface. Je prend mon temps, pour peaufiner, ce qui est un véritable plaisir, trop rare en production. En outre, cela m’amène à certaines réflexions sur le code sous-jacent.
Normalement, la logique du code aurait dû être issue des uses-cases. Cependant, étant donné la nature très expérimentale (pour moi) de ce projet, il était assez difficile de concevoir toute l’architecture du code et l’interface correspondante avant de me plonger dans le code. En fait, avant de commencer, je n’étais pas sûr d’arriver à lister le contenu d’un repository Mercurial dans django, et je n’imaginais pas vraiment faire l’authentification par django ! Ce projet est donc allé beaucoup plus loin que je ne le pensais, ce qui explique que le code soit amené à évoluer.
Bref, je me suis rendu compte que django_hg avait 3 niveaux (entre parenthèses, le nom de la vue correspondante dans django_hg) :
- la liste des repositories (
list) ; - différentes vues d’un repository : parcourir (
browse), lister les révisions (changesets), afficher une révision (changeset) et afficher un aperçu général (overview) - différentes vues d’un fichier au sein d’un repository: les révisions qu’a connu ce fichier (
filelog), afficher du code source ou d’un aperçu pour les images et les pdfs (filerev), les différences entre 2 révisions (filediff, très loin encore d’être opérationnel)
Du point de vue de l’interface, ces trois types de fichiers utilisent des templates différents. Mais je suis en train de me dire que je pourrais refactoriser mon code pour qu’il n’ait que 3 vues, avec pour certains, plusieurs cas de figure.
Cela ne vas toutefois pas être pour tout de suite, car je voudrais avancer sur les considérations graphiques avant. À ce propos, quelles sont les bonnes pratiques pour distribuer des ressources graphiques (images, css, …) pour une application réutilisable ?
