structuration du dossier de travail BLOB 0

pour le moment, BLOB a été plutôt pensé comme un dépôt git construisant et constituant un numéro. C'est-à-dire qu'un dossier rassemble tous les éléments constituant le numéro, que ce soit le contenu (textuel, image, autre), les outils permettant sa mise en page ainsi que le serveur permettant de visualiser le tout.

Les deux externalités finales de ce dossier sont les PDF (à cause de quelques détail de compatibilité PDF, nous avons dû en générer deux, l'un pour l'impression chez Lulu et l'autre pour la lecture à l'écran) ainsi que le site web du numéro, c'est à dire un fichier HTML, les contenus médias (images) ainsi que tous les éléments statiques de mise en page web (CSS, js, fontes).

Cette manière de procéder permet à plusieurs personnes de travailler sur le projet via git sur leurs dépots locaux et de pouvoir visualiser le résultat au complet (avec des variations dues aux navigateurs et aux OS qu'ils utilisent). L'utilisation de Github permet d'avoir une autre manière de participer au projet via un éditeur de texte dans une interface web, sans devoir installer git ni télécharger tout le projet, pour éditer les contenus par exemple.

Par contre il faut tout télécharger et manier un peu ligne de commande pour visualiser le résultat d'une manière autonome (sans demander la génération d'un PDF ou le déploiement d'un serveur accessible depuis le net)

Cette manière de faire pourrait évoluer vers une séparation plus nette entre les différentes briques du projet, mais elle permet de considérer de la même manière toutes formes de textes (contenus, feuilles de style et codes) et ainsi inciter tous les participants à tout éditer sans hérarchie, git s'occupant de tout versionner pour éviter les drames.

De plus, considérer chaque numéro comme autonome permet de choisir explicitement la conservation ou non des éléments éditoriaux, techniques et graphiques des précédent numéros sans qu'ils soient considérés comme des simples reliquats et de partir à chaque fois sur des bases techniques "saines" et mises à jour. C'est pour cela que je tente une documentation plus "de principe" qu'une véritable documentation technique. Même si la structure présenté ici a fonctionné, je pense qu'il est parfois préférable de « réinventer (un peu) la roue » pour pouvoir se réapproprier le projet (« se sentir chez soi ») puisque l'échelle et la complexité du projet fait que l'on peut vite faire le tour du propriétaire et y entamer les travaux nécéssaires.

Si on reprend la structure du dépôt git présenté dans le fichier /readme.md :

dist/
    public/
        css/
        	book.css
        js/
            paged.js
        images/
    index.html
    *.js

sources/
    cover.md
    introduction.md
    chapitres/
        *.md

src --
    *.ts

1. Le dossier /sources/ contient ce qu'on peut considérer comme les sources du contenus de la revue. on y trouvera les fichiers Markdown ou HTML des différentes parties de la revue. D'une manière générales, les articles/chapitres sont en Markdown pour que les auteurs/correcteurs puissent les lire, les comprendre et les éditer facilement. Mais les autres parties sont directement en HTML pour qu'elles soient plus précisément structurables:

   • Le fichier head.html contient les métadonnées de la page web qui constituera la revue, il a donc des éléments très spécifique au web (import de fichiers JS et CSS, encodage...).
   • le reste se trouve répartie au milieu selon la structure de la revue: cover.html ; preface.md ; les chapitres dont leurs versions générées en HTML se retrouve dans le dossier chapitres/ ; colophon.html.
   • le fichier footer.html qui sera la dernière partie qui clôture la page HTML

2. Le dossier src/ contient les sources du code côté serveur. Le choix a été fait de coder cette partie en TypeScript, un langage qui est ensuite converti en JavaScript, pour tenter de constituer un programme plus "sain" et faciliter le débuguage du reste de la chaîne d'édition.

3. Le dossier dist/ contient les fichiers qui sont effectivement "performatifs", qui constituent le programme.

   • À la racine se trouve les fichiers .js (les mêmes codes que les .ts du dossier src/ mais maintenant converti en javascript) qui sont "exécutés" par le serveur au moment de son lancement ou d'un signal de mise à jour.
   • LE fichier index.html qui est effectivement servi à notre navigateur lorsque l'on visualise le résultat (fabriqué à partir de tout ce qu'il y a dans le dossier sources/).
   • Le dossier public/ qui contient les autres briques de notre projet : les feuilles de styles et les fontes, les scripts JS qui permettent de manipuler le contenu dans le navigateur ainsi que les médias présentés dans la page web (images...).

Il est très important de comprendre la place des fichiers dans la "chaîne" de conversion du projet, pour ne pas perdre du temps à éditer un fichier (qui change effectivement le résultat visualisé) mais qui sera écrasé et remplacé par une nouvelle version lors de l'édition d'un autre fichier ou le redémarrage du serveur. Grossièrement, des fichiers sont là pour nous les humains et que d'autres sont seulement manipulés par le serveur. Pour bien les différenciés et organiser le dépôt git, le fichier .gitignore permet d'exclure justement tous les fichiers qui sont générés par le programme de la sauvegarde et du versionnage du dépôt puisqu'ils ne sont pas nécessaires à son exécution puisque généré « à la volée ».

fonctionnement du serveur de développement:

une fois Node installé :

• npm install dans le dépot git une fois cloné pour installer les modules node.js
• npm run watch-ts lance un deamon qui va « transpiler » des sources du serveur à chaque fois qu'elles sont éditées
• npm run watch-node lance un deamon qui va relancer le serveur à chaque nouvelle transpilation (par contre il doit être relancé à la main lors de l'édition des autres sources du projet (markdown, html...))

on a donc trois étapes distinctes, la transpilation des sources du serveur (elle existe seulement parcequ'elles sont écrites en TypeScript) puis le lancement ou le restart du serveur (conversion et manipulation des fichiers sources de la revue en source web) et enfin lorsque l'on va sur l'adresse localhost:3000 avec un navigateur et que le contenu est servi et présenté.