Skip to content
Sébastien Beyou edited this page Feb 22, 2019 · 3 revisions

~ ARCHIVE ~


Le site archeo-lex.fr est une vitrine du programme Archéo Lex, ce dernier n’étant en soi qu’un programme de traitement qui n’est ni visuel, ni utilisable par des non-informaticiens. Ainsi, ce site rend les résultats d’Archéo Lex réellement utilisable par la communauté de l’information légale.

Le site est hébergé sur mon serveur personel (un DreamPlug, i.e. un micro-serveur) derrière une ligne ADSL. S’il nécessite plus de ressources, je le déplacerai sur un vrai serveur plus puissant avec une meilleure connexion (si vous avez un bout de serveur de dispo pour le site archeo-lex.fr, je suis intéressé).

L’interface web de Git est GitList, que je trouve assez utilisable et jolie, en plus d’être proche de celle de GitHub (elle-même jolie et utilisable).

Structure et URLs

Prévu :

  • archeo-lex.fr/aide/ Aide sur l’utilisation du site et surtout des concepts (Git pour les praticiens du droit non-informaticiens, légistique pour les informaticiens non au fait de la chose légistique)

Prévu, mais un développement spécifique est requis (cf partie suivante de cette page) :

Questions globales sur les URLs
  • quelles URLs utiliser pour les téléchargements Git ? archeo-lex.fr/git/dépôt ou archeo-lex.fr/codes/dépôt ou autre (pas de difficulté technique majeure quel que soit le choix)
  • franciser les URLs de GitList ? (pas de difficulté technique majeure)
  • pour la lecture en ligne des dépôts Git, utiliser une adresse dédiée à un outil, genre archeo-lex.fr/gitlist/ ? comment péréniser les URLs données par cet outil ? (notamment en cas de changement d’outil)
Réflexions sur la création d’URLs adaptées
Sur la structure des URLs et leur usage

La structure proposée ci-dessus est-elle adaptée ?

Elle tente de hiérarchiser les informations :

  • livraison de la base LEGI, optionnel sinon dernière livraison
  • type de loi, pour l’instant uniquement "codes", possiblement dans le futur "loi", "décret", "ordonnance", "loi_organique", "loi_constitutionnelle" (à définir exactement, suivre les catégories de la base LEGI ?)
  • nom de la loi, en bas de casse, avec les accents, dont les espaces sont remplacées par des tirets bas (_) pour affichage uniforme entre navigateurs (parfois les espaces sont affichées comme des espaces, parfois %20)
  • date de vigueur du texte, au format AAAA-MM-JJ, normalement le premier jour de vigueur, redirection permanente (HTTP 301) vers le premier jour de vigueur de la même version le cas échéant
  • deuxième date pour comparaison avec la première, au format AAAA-MM-JJ, normalement les premiers jours de vigueur et redirection le cas échéant, pour affichage d’un diff entre les deux versions

Questions :

  • faut-il rediriger vers les premiers jours de vigueur ? (pour obtenir des URLs "canoniques")
  • faut-il permettre et comment comparer les versions d’une même date de vigueur à livraisons différentes ? (pour voir les évolutions éditoriales)
  • les différents choix typographiques sont-ils adaptés ?
  • dans la gestion des dates, il peut y avoir entre 0 et 3 dates dans l’URL : lesquels ? où les placer ? (0=dernière livraison, version en vigueur ; 1=dernière livraison, version datée OU livraison datée, dernière version ; 2=dernière livraison, versions datées comparées ; 3=livraison spécifiée, versions datées comparées OU livraisons comparées, version datée spécifiée)
Implémentation technique

Proposition :

  1. Créer une base de données (SQLite ?) avec les correspondances date → commit
  2. Utiliser le module Lua de nginx pour réécrire (en interne, pas en redirection HTTP) vers une instance GitList (ou autre affichage Git bien sûr)
  3. Possiblement utiliser une instance GitList dédiée et épurée, pour utilisation plus simple pour les non-informaticiens