Achille est un logiciel permettant de répondre à un problème simple : entretenir facilement un petit site composé de pages statiques. Il permet de transformer un ensemble de documents de différents formats en une architecture de pages XHTML, tout en créant des index et quelques autres facilités.

Histoire

Achille a tout d'abord été implémenté sous la forme d'un ensemble de scripts. Ce système ne nécessitait rien d'autre que le shell bash, awk, l'éditeur sed, la DTD DocBook et un outil de formattage XSLT tel xsltproc. Ces logiciels sont disponibles pour de nombreux systèmes, notamment toutes les versions d'Unix libres.

L'objectif de la version 2.0 d'Achille a été de transformer cet ensemble de scripts en un vrai programme. Le langage choisi est Python, disponible aussi bien sous MS Windows qu'un UNIX ou Macintosh. Python possède une bibliothèque standard extrêmement bien fournie, mais la gestion des documents XML avec XPath et XSLT nécessite l'utilisation d'une bibliothèque tierce. PyXML n'étant pas suffisamment avancée pour mes besoins au moment où j'ai débuté le développement, j'ai choisi dans un premier temps choisi d'utiliser 4Suite. Puis j'ai découvert lxml et ai porté le programme sur cette bibliothèque.

Achille a été conçu avec un souci particulier pour l'accessibilité, c'est à dire la possibilité d'accéder à l'information quels que soient le matériel et les possibilités physique des personnes. Ainsi, les pages produites sont conformes aux normes XHTML 1.1 et CSS 2 et peuvent être affichées correctement par n'importe quel navigateur moderne. Les navigateurs plus anciens ou ne supportant pas CSS, ou encore tout autre outil sachant lire le langage HTML est capable d'afficher le contenu de ces pages, de manière dégradée.

Limitations

Depuis le tout début de son développement, Achille est très fortement lié au format Docbook. Ceci se comprend car les seuls documents que j'ai souhaité publier jusqu'ici, et pour lesquels j'ai écrit Achille sont au format Docbook. Pire, les transformations XSLT se basent sur un sous-ensemble maison de Docbook. Cette façon de procéder limite énormément l'intérêt du logiciel.

La création des menus ou la mise en place des feuilles CSS sont un hack moyennement correct. Généraliser ces manipulations pour permettre d'ajouter d'autres informations sur la page générée n'est pas envisageable.

Vision

Comme l'annonce la description du projet chez TuxFamily, Achille doit devenir un moteur pour pouvoir publier n'importe quel document sur le web, sans poser aucune contrainte sur ces documents. Pour cela, le coeur d'Achille doit subir une importante mise à jour afin de se débarrasser de toute dépendance forte sur un format de document, et de pouvoir s'appuyer sur des outils éprouvés.

La transformation des documents doit pouvoir se faire de manière générique, quel que soit le type de document. Mieux encore, la génération des pages complémentaires comme les index ou la carte du site doit pouvoir se faire de manière aussi transparente que possible, en exploitant les mêmes mécanismes génériques de transformation.

Des fichiers virtuels

Pour s'inscrire dans cette vision, le programme doit être vu comme une collection d'objets de transformation. Ces objets prennent un fichier en entrée, et produisent un nouveau fichier HTML en sortie.

Afin de traiter de manière identique les fichiers dynamiquement produits que les fichiers originaux à publier, les objets de transformation travaillent en réalité sur des fichiers virtuels. Un tel objet présente l'interface d'un fichier (ouvrir, lire, etc.) mais peut cacher aussi bien l'accès direct à un fichier physique qu'un objet complexe qui produit son contenu sur la base d'autres informations.

La configuration d'Achille doit refléter cela. Un site est un ensemble de sections — ou répertoires — comportant des fichiers. Les fichiers devant être publiés proviennent d'un fichier source, et les fichiers générés proviennent d'une directive adressée à Achille, et d'un ensemble d'informations.

<?xml version="1.0" encoding="ISO-8859-15"?>
<site target='doc/html'
         xmlns:fill='http://achille.tuxfamily.org/xmlns/2.0/fillers'>

  <section id='root' target='/'>
    <src path='sources/xml' />
    <fill:summary>
      <section-id>root</section-id>
    </fill:summary>
  </section>
  
</site>

Ci-dessus, la section root contient des sources et une directive afin de créer un fichier d'index de type sommaire. Concrètement, Achille va invoquer un objet de transformation pour chaque fichier contenu dans sources/xml, et un objet de traduction pour transformer le résultat de la directive summary.

Toute directive se traduit par un objet dit de remplissage (Filler). Les applications pratiques premières sont la création des index, de cartes du site, ou de tout autre pages reposant sur les données issues des documents sources.

Chaque section pouvant disposer de multiples sources, Achille ne travaille que sur le répertoire de destination. Les chemins sources ne reçoivent aucun fichier temporaire ou final. Nettoyer les fichiers produits par Achille consiste simplement à effacer le répertoire de destination du site à produire.

Une transformation générique

Tout type de transformation — d'une simple copie à la transformation d'un document Docbook, LaTeX ou autre — est donc gérée par un objet particulier. Cet objet de transformation est normalement choisi en fonction du type de la source (en général, selon son extension). Cependant, il est possible de définir par configuration le type de transformation souhaité. Ce choix se définit pour chaque source déclarée afin de permettre de définir une transformation différente même pour des types de documents identiques (par exemple pour publier un document et sa source non transformée).

<?xml version="1.0" encoding="ISO-8859-15"?>
<site target='doc/html'
         xmlns:fill='http://achille.tuxfamily.org/xmlns/2.0/fillers'>

  <section id='root' target='/'>
    <src path='sources/xml' translator='DocbookTranslator' />
    <src path='sources/html' translator='XHTMLTranslator' />
    <fill:summary>
      <section-id>root</section-id>
    </fill:summary>
  </section>
  
</site>

Les objets de remplissage, étant traités comme n'importe quelle autre source, fournissent donc également le type de leur objet de transformation. Cependant l'objet de transformation utilisé par ces sources n'est pas modifiable par configuration.

Du fait de la transformation générique, fichier par fichier, il devient possible également de ne procéder à la transformation que si la source est plus récente que la cible. Les objets de remplissage devraient retourner la date d'édition la plus récente des fichiers qu'ils référencent, ou plus simplement l'heure courante afin d'être reproduit à chaque invocation d'Achille.

Voici une hiérarchie d'objets de transformation possible :

Translator
|
|---> DocBookTranslator
|      Transforme un document Docbook en XHTML.
|
|---> RDFTranslator
|      Transforme les documents RDF en pages XHTML.
|
|---> CopyTranslator
|      Copie le fichier source vers le chemin destination sans aucune
|      transformation.
|
|---> XBelTranslator
|      Génère une page XHTML comprenant une liste de liens.
|
 ---> LateXTranslator
       Transforme un document LaTeX en page XHTML.

Production finale

À l'issue de la transformation des documents, le site est composé de pages XHTML et de documents divers (images, feuilles de styles, archives, fichiers non transformés, etc.). Parmis tous ces documents, les pages XHTML, et peut-être certains autres documents textes, doivent s'inscrire dans un style uniforme et paramétrable.

Cette mise en page finale est définie par une feuille XSLT appliquée aux documents produits. Cette feuille permet de fournir le cadre de la page, mais peut également permettre la création automatique de sommaire, ajouter un appel à des routines PHP ou introduire du Javascript pour dynamiser le rendu final.

Cette mise en page finale peut nécessiter des informations diverses afin d'améliorer les pages produites ; titres, auteur, nom de la feuille de style, etc. . Ces informations supplémentaires, ou méta données, s'appliquent au site en entier, à une section ou à une source en particulier. Leur caractère est facultatif, et elles ne sont que transmises par Achille à la feuille XSLT qui peut les ignorer ou non pour la mise en forme des pages.

<?xml version="1.0" encoding="ISO-8859-15"?>
<site target='doc/html style='sources/xsl/final.xsl'
         xmlns:fill='http://achille.tuxfamily.org/xmlns/2.0/fillers'
         xmlns:meta='http://achille.tuxfamily.org/xmlns/2.0/meta>

  <meta:title>Achille 2.0</meta:title>
  <meta:css-sheet name='Standard' path='simple.css' />
  <meta:menu>
    <section-id>root</section-id>
  </meta:menu>

  <section id='root' target='/'>
    <meta:title>Achille</meta:title>
    <src path='sources/xml' translator='DocbookTranslator' />
    <src path='sources/html' translator='XHTMLTranslator' >
      <meta:author>Dupont</meta:author>
    </src>
    <fill:summary>
      <section-id>root</section-id>
    </fill:summary>
  </section>
  
</site>

Un fonctionnement extensible

Les objets de remplissage, de transformation, ou la définition des méta données ne sont pas figées. Achille se base sur un système de greffons permettant d'ajouter ou de retirer de tels éléments à chaque exécution du programme. L'utilisateur peut en outre indiquer une liste de chemins quelconques à l'invocation d'Achille. Ces chemins sont explorés pour trouver des greffons, lesquels on la priorité sur les objets normalement utilisés.

Feuille de route

La révision 2 du code présent sur TuxFamily constitue la version limitée disponible au moment de la rédaction de cette vision du futur d'Achille. Une documentation pas tout à fait à jour et non maintenue de cette version est disponible sur ce site. Cette version doit faire l'objet des modifications suivantes, à peu près dans cet ordre.

Ce site est régulièrement regénéré avec la version la plus à jour d'Achille.

Suivi de ce document