Note à propos des « Content Repository » dans le cadre d'un CMS

Dimanche dernier, j'ai étudié le thème « Content Repository », voici quelques notes concernant mes recherches.

Séparation des Web CMS en deux couches

J'ai trouvé un article qui fait la distinction entre deux types de CMS, enfin il parle de WCMS (Web CMS) :

  • « Content Production Systems (CPS) »
  • « Presentation Management Systems (PMS) »
Personnellement, cet article me fait penser à une réflexion qui m'est déjà venu de nombreuses fois : là où l'auteur de l'article voit deux systèmes, deux types d'applications distinctes, je vois en fait deux couches… Bon en fait, l'auteur semble le dire aussi à la fin de son article quand il parle de CPS + PMS.
Je reprends ci-dessous à peu près la description qu'il fait d'un CPS et d'un PMS :
  • CPS - c'est le système qui gère la couche données, la logique métier du CMS, comme :
    • l'enregistrement des ressources (Pages, Images, Dossiers…)
    • un moteur de recherche plain texte (avec filtre…)
    • un workflow
    • un système de versionning
    • import / export de données
  • PMS - c'est le système qui pour résumer "affiche" les pages :
    • la navigation
    • système de template
    • layouts
    • skins / thèmes
    • back office d'édition

« Content Repository »

À mes yeux… je ne fais pas bien la distinction entre un Content Repository et un CPS.

Si j'essaie de les différencier, je dirais qu'un Content Repository est une librairie ou un serveur alors qu'un CPS est une application, avec des Interfaces Utilisateur…

Dans la suite de l'article, je vais partir du principe que Content Repository est la même chose qu'un CPS même si ce n'est pas totalement exact.

Dans le monde Java, une spécification nommée JCR (Java Content Repository) décrit ce qu'est un Content Repository et comment l'utiliser (spécification d'une API standard).

Il existe plusieurs implémentations de JCR mais la plus connue semble être Jackrabbit de la fondation Apache. Je l'avais rencontré il y a quelque années lorsque j'ai étudié de loin Nuxeo.

J'ai été agréablement surpris de découvrir les projets PHP suivants (ce qui confirme que je ne suis pas le seul à me poser ces questions) :

J'ai appris l'existence d'un projet de Content Repository pour Node.js :

J'ai aussi trouvé Lily qui est un Content Repository basé sur Hadoop, HBase et SOLR dans un écosystème Java + API Rest.

Spécificités techniques d'un CPS

J'ai trouvé un autre article qui traite des spécificités techniques d'un CPS. Voici ci-dessous sa liste de "requirements" :

  • Richly structured content types
  • Unstructured binary objects
  • Relationships / references / associations
  • The ability to evolve content models over time (what I call “schema evolution”)
  • Branch / merge (in the Source Code Management (SCM) sense of the term)
  • Snapshot based versioning
  • ACID transactions
  • Scalability to large content sets
  • Geographic distribution

Chacun de ces points sont détaillés dans son article et c'est fortement intéressant. Par exemple, je trouve le point « Branch / Merge » très juste… bien que je ne sache pas tout à fait comment l'implémenter simplement.

À partir de cette liste, voici la liste des "requirements" de mon Content Repository idéal :

  • Base de données où je peux stocker des objects JSON ainsi que des blobs (exemples : base de données NoSQL comme MongoDB, CouchDB)
  • Base de données où je peux stocker des collections (pour des dossiers), des liens (pour des redirections), des associations (pour des catégories, des tags…)
  • API Rest qui permettent d'accéder plus ou moins à toutes les features du Content Repository
  • Moteur de recherche (basé par exemple sur : Xapian, elasticsearch)
  • Un système de workflow
  • Versionning (peut-être basé sur Git ou Mercurial)
  • Système d'import / export de données (je ne sais pas si il y a un format standard pour les CMS… enfin je n'ai jamais trouvé)
  • Support d'une API CMIS (bien que je la trouve peu élégante… c'est bien une API faite par le monde Java)
  • Accès WebDAV
  • Gestion des utilisateurs

Pour le moment, je n'ai pas trouvé le Content Repository de mes rêves.

Le standard CMIS « Content Management Interoperability Services »

Le standard CMIS est un autre élément intéressant à prendre en compte dans un CPS.

CMIS est une couche d'abstraction dont le but est de permettre de faire communiquer plusieurs instances de CMS identiques ou différentes ensemble. Elle doit permettre par exemple d'importer les données d'une instance à une autre.

Il existe de nombreux clients CMIS pour différent langage…

La suite…

J'ai prévu d'écrire d'autres billets à propos des Content Repository :

  • Un retour d'expérience et mes réflexions concernant un premier Content Repository que j'ai écrit en Python, basé sur la base de données NoSQL ZODB et le moteur de recherche Whoosh. Il comporte aussi un connecteur WebDAV.

  • Un autre billet sur une proposition d'API RESTful pour un Content Repository… quelque chose de naturel et vraiment dans l'esprit RESTful.

    Exemple :

    GET http://example.com/blog/my-post         => est dans l'esprit RESTful
    GET http://example.com/post?name="my-post"  => est moins dans l'esprit RESTful
    

    Dans l'API REST de CMIS j'ai trouvé beaucoup de requête suivant la seconde forme d'URL et très peu ou pas sous la première forme d'URL.

Read and Post Comments

Mes flux :