« Billets plus récentsBillets plus anciens »

Ember.js - Épisode 2 - Déclarer un tableau dans une classe

Après un premier billet intitulé « Ember.js - Épisode 1 - Présentation de l'application feuille de matchs » voici un second billet à propos de Ember.js où je vais présenter comment résoudre le problème assez trivial que j'ai rencontré lors de la déclaration d'une propriété de type tableau dans une classe.

Note : je ne sais pas si j'ai bien réussi à doser le niveau de ce billet… je pense que par moment j'ai expliqué des concepts trop basiques de Ember.js. J'attends vos remarques à ce sujet dans les commentaires.

Les fonctions "create" et "extend" de Ember.js

Tout d'abord, voyons les différences entre Ember.Object.create et Ember.Object.extend.

Pour créer un objet avec Ember.js, vous devez utiliser la fonction suivante :

MyApp.contact1 = Ember.Object.create({
    firstname: 'Stéphane',
    lastname: 'Klein'
});

Pour créer une classe, vous devez utiliser la fonction suivante :

// Création de la classe
MyApp.Contact = Ember.Object.extend({
    sayHello: function() {
        alert('Hello');
    }
});

// Création de deux objets de type "Contact"
MyApp.contact1 = MyApp.Contact.create(
    firstname: 'Stéphane',
    lastname: 'Klein'
);
MyApp.contact2 = MyApp.Contact.create(
    firstname: 'Thomas',
    lastname: 'Petit'
);

MyApp.contact1.sayHello();

Vous l'aurez compris :

  • create permet de créer un objet
  • extend permet de créer une classe

Pour plus d'information à ce sujet, je vous invite à consulter la documentation de Ember.js.

Dans l'exemple de ce billet, j'ai besoin d'utilser la commande "Ember.Object.extend" pour déclarer une nouvelle classe.

Description de la classe que je souhaite créer

Je souhaite créer une classe nommée "Game" qui représente un match dans la feuille de matchs (vous pouvez retrouver la description de l'application dans le premier billet).

Cette classe "Game" doit remplir les objectifs suivants :

  • stocker les scores des sets du match
  • calculer le nombre total de points du match (ceci n'a en fait aucune utilité dans mon application mais c'est une fonction utile dans l'exemple de ce billet… car il illustre très bien la problématique)

Je veux pouvoir faire des choses comme :

MyApp.game_1 = MyApp.Game.create({});

MyApp.game_1.sets[0] = 5; // Attention ici "sets" correspond à des sets d'un match
MyApp.game_1.sets[1] = 2;

console.log(MyApp.game_1.total()); // retourne 7

Première implémentation qui ne fonctionne pas comme souhaité

Voici une première version de ma classe "Game" qui ne fonctionne pas comme souhaité.

Dans main.js :

MyApp = Ember.Application.create();

MyApp.Game = Ember.Object.extend({
    sets: [ // Attention, ici "sets" correpsond à des sets d'un match
        Ember.Object.create({ value: '' }),
        Ember.Object.create({ value: '' }),
        Ember.Object.create({ value: '' }),
        Ember.Object.create({ value: '' }),
        Ember.Object.create({ value: '' })
    ],
    total: function() {
        var total = 0;
        this.sets.forEach(function(item) {
            if (
                (item.value != '') &&
                (!isNaN(item.value))
            ) {
                total += parseInt(item.value);
            }
        });
        return total;
    }.property('sets.@each.value')
});

MyApp.games = [
    MyApp.Game.create(),
    MyApp.Game.create(),
    MyApp.Game.create()
]

Explication du code source :

  • ligne 1 : je déclare l'application
  • ligne 3 : je déclare la nouvelle classe nommée "Game"
  • lignes 4-10 : déclaration de la propriété sets avec des scores de sets vides (attention, ici un sets correspond à des sets de matchs)
  • lignes 11 à 22 : déclaration de la méthode total. Cette méthode parcourt tous les éléments de la propriété sets et fait la somme de ses valeurs en transformant la valeur des sets en entier…
  • ligne 22 : "l'annotation" property, indique que la valeur de la méthode total change dès qu'une proriété value de la propriété sets est modifiée
  • lignes 25-29 : création de 3 objet de type Game dans un tableau nommé games

Voici ci-dessous, le template qui utilise la couche modèle qui vient d'être défini (les instances dans "MyApp.games" et la classe "MyApp.Game").

Dans index.html :

<body>
<script type="text/x-handlebars">
  <h1>Game 1</h1>
    <ul>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.0.sets.0.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.0.sets.1.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.0.sets.2.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.0.sets.3.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.0.sets.4.value"}}
      </li>
    </ul>

  <p>Total : {{MyApp.games.0.total}}</p>

  <h1>Game 2</h1>
    <ul>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.1.sets.0.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.1.sets.1.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.1.sets.2.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.1.sets.3.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.1.sets.4.value"}}
      </li>
    </ul>

  <p>Total : {{MyApp.games.1.total}}</p>

  <h1>Game 3</h1>

    <ul>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.2.sets.0.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.2.sets.1.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.2.sets.2.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.2.sets.3.value"}}
      </li>
      <li>
        {{view Ember.TextField valueBinding="MyApp.games.2.sets.4.value"}}
      </li>
    </ul>

  <p>Total : {{MyApp.games.2.total}}</p>
</script></body>

Explication :

  • ligne 2 : balise d'ouverture un bloc template de Ember.js
  • ligne 6 : cette "view" crée une balise du type <input type="text"…, ce champ input est directement connecté avec l'objet MyApp.games.0.sets.0.value de la couche modèle. Ce qui veut dire que lorsque cet objet est mise à jour du coté de la couche modèle alors le champ input est directement mise à jour. Inversement, si je champ input est mise à jour via l'Interface Utilisateur alors la couche modèle est mise à jour automatiquement.
  • ligne 22 : la valeur retournée par la méthode MyApp.games.0.total est affichée et elle est automatiquement mise à jour… grâce à l'annotation property('sets.@each.value')
  • lignes 22-42 : affichage de la seconde instance MyApp.games.1
  • lignes 45-65 : affichage de la troisième instance MyApp.games.2

Vous pouvez tester cette implémentation en live sur jsFiddle.

Qu'est ce qu'il ne fonctionne pas dans cette implémentation ?

Dans cette implémentation, lorsque l'on modifie la valeur des sets d'une instance, par exemple « Game 1 », les champs des autres matchs « Game 2 » et « Game 3 » sont eux aussi mise à jour avec les mêmes valeurs.

Toutes les instances de classe de type "Game" partagent les mêmes données !

Pourquoi ?

Parcequ'un objet de type tableau est directement affecté à la propriété sets de la classe Game lors de sa déclaration… ce tableau est créé une fois… et est donc identique et partagé par toutes les instances de type Game.

La bonne solution : déclarer le tableau dans le constructeur

Voici maintenant l'implémentation qui fonctionne comme voulu.

Dans main.js :

MyApp = Ember.Application.create();

MyApp.Game = Ember.Object.extend({
    init: function() {
        this._super();
        this.set('sets', [
            Ember.Object.create({ value: '' }),
            Ember.Object.create({ value: '' }),
            Ember.Object.create({ value: '' }),
            Ember.Object.create({ value: '' }),
            Ember.Object.create({ value: '' })
        ]);
    },
    total: function() {
        var total = 0;
        this.sets.forEach(function(item) {
            if (
                (item.value != '') &&
                (!isNaN(item.value))
            ) {
                total += parseInt(item.value);
            }
        });
        return total;
    }.property('sets.@each.value')
});

MyApp.games = [
    MyApp.Game.create(),
    MyApp.Game.create(),
    MyApp.Game.create()
]

Le fichier index.html est exactement identique à la première implémentation.

Tester cette version en live sur jsFiddle.

Explications :

  • lignes 4-13: cette fois, un constructeur (méthode init) est déclaré
  • ligne 5 : cette ligne importante pour le bon fonctionnement d'une classe Ember.js
  • ligne 6 : ici est la subtilité, il faut absolument passer par la méthode set pour ajouter une nouvelle propriété à la classe
  • ligne 7-11 : ajout de 5 objets directement dans le tableau

Cette fois, cette implémentation fonctionne comme voulu car chaque instance de type Game contient un tableau différent.

Attention à ne pas utiliser la méthode "push" mais bien "pushObject"

Voici une autre subtilité, l'exemple ci-dessous ne fonctionne pas comme souhaité car il utilise la méthode push de la classe Array.

Dans main.js :

MyApp = Ember.Application.create();

MyApp.Game = Ember.Object.extend({
    init: function() {
        this._super();
        this.set('sets', Ember.A([]));
        this.get('sets').push(Ember.Object.create({ value: '' }));
        this.get('sets').push(Ember.Object.create({ value: '' }));
        this.get('sets').push(Ember.Object.create({ value: '' }));
        this.get('sets').push(Ember.Object.create({ value: '' }));
        this.get('sets').push(Ember.Object.create({ value: '' }));
    },
    total: function() {
        var total = 0;
        this.sets.forEach(function(item) {
            if (
                (item.value != '') &&
                (!isNaN(item.value))
            ) {
                total += parseInt(item.value);
            }
        });
        return total;
    }.property('sets.@each.value')
});

MyApp.games = [
    MyApp.Game.create(),
    MyApp.Game.create(),
    MyApp.Game.create()
];

Tester l'exemple en live sur jsFiddle.

Exemple qui fonctionne avec l'utilisation de pushObject :

MyApp = Ember.Application.create();

MyApp.Game = Ember.Object.extend({
    init: function() {
        this._super();
        this.set('sets', Ember.A([]);
        this.get('sets').pushObject(Ember.Object.create({ value: '' }));
        this.get('sets').pushObject(Ember.Object.create({ value: '' }));
        this.get('sets').pushObject(Ember.Object.create({ value: '' }));
        this.get('sets').pushObject(Ember.Object.create({ value: '' }));
        this.get('sets').pushObject(Ember.Object.create({ value: '' }));
    },
    total: function() {
        var total = 0;
        this.sets.forEach(function(item) {
            if (
                (item.value != '') &&
                (!isNaN(item.value))
            ) {
                total += parseInt(item.value);
            }
        });
        return total;
    }.property('sets.@each.value')
});

MyApp.games = [
    MyApp.Game.create(),
    MyApp.Game.create(),
    MyApp.Game.create()
];

Tester l'exemple en live sur jsFiddle.

Explication :

  • Lorsque l'on utilise un tableau qui doit être observé par Ember.js, il est important d'utiliser la méthode pushObject et non pas push sinon property('sets.@each.value') ne fonctionne plus.

Dans le cadre de l'application « Feuille de matchs »

L'application « Feuille de matchs » met en oeuvre ce que l'on a vu ci-dessus.

J'ai perdu pas mal de temps avec la subtilité d'utiliser this.set dans le constructeur. J'ai aussi perdu du temps car j'ai utilisé par erreur la méthode push à la place de pushObject.

J'espère que ce billet vous sera utile et qui vous évitera de perdre du temps là où j'en ai perdu.

Read and Post Comments

Ember.js - Épisode 1 - Présentation de l'application feuille de matchs

Je souhaite écrire une série de billets à propos de Ember.js, un framework Javascript qui permet d'écrire des applications webs.

J'ai commencé à étudier et à expérimenter Ember.js il y a quelques semaines.

C'est le billet « Une bien belle mise à jour » sur le blog du service Capitaine Train (n'hésitez pas à me contacter si vous souhaitez recevoir une invitation à ce super service en ligne) qui m'a donné envie d'étudier Ember.js.

J'avais déjà croisé cet outil par le passé… mais j'avais vite zapé car je n'avais pas vu l'intérêt de ce énième framework javascript.

Une série de billets sur le développement d'une application web ?

Je souhaite réaliser ma série de billets à propos de Ember.js sous la forme d'un récit du développement d'une petite application web, mettant en oeuvre entre autres : Ember.js (Javascript coté client) et Pyramid (en Python coté serveur).

Pourquoi sous cette forme ? Et bien parce que je pense qu'un exemple complet de réalisation d'une application (que je souhaite dans tous les cas réaliser) peut être une bonne source d'information pour ceux qui veulent se lancer avec Ember.js et Pyramid.

À noter… que vous pourrez apprendre des choses uniquement sur Ember.js sans avoir l'obligation d'étudier Pyramid… et inversement.

Mes premiers contacts avec Ember.js

Ma rencontre avec Ember.js a suivi ces étapes :

  1. j'ai regardé vite fait… je n'ai pas vu son potentiel
  2. j'ai regardé un peu plus la documentation… et c'est la partie suivante de la documentation qui a attiré mon attention « Computed Properties (Getters) »
  3. j'ai fait un petit exemple rapide… j'ai été impressionné par la fonctionnalité suivante de Ember.js (qui est son cœur… sa raison d'être) :
    • lorsque l'on modifie les données au niveau de la couche modèle… le rendu de la page est automatiquement mis à jour (en rejouant le ou les templates présents dans la page)
    • lorsqu'il y a une interaction utilisateur au niveau de l'UI… les données de la couche modèle sont automatiquements mis à jour
  4. j'ai commencé à réaliser un premier projet plus concret… et je suis très vite resté bloqué sur des problèmes… que j'ai maintenant réussi à résoudre mais après beaucoup de recheches

Ma conclusion :

  • Ember.js semble être un super outil…
  • Ember.js manque encore de documentation… et surtout des exemples

À travers le récit du développement de l'application « Feuille de matchs » je souhaite justement partager les difficultés que j'ai rencontré et indiquer des solutions.

Avertissement

Je n'ai pas beaucoup d'expérience sur Ember.js, dans ce billet et dans les billets suivants… je ne vous dis pas qu'il faut absolument que vous utilisiez cet outil.

Peut être que dans six mois je vais m'apercevoir et conclure que cet outil a plein d'inconvénients, plein de limitations… mais pour le moment j'adore… tout va bien à part le manque de documentation.

Je pourrai vous en dire plus… quand j'aurai développé une ou deux applications webs basées sur Ember.js.

Présentation rapide de l'application

Je fais du Tennis de Table en compétition depuis plusieurs années.

Voici la feuille de match d'une rencontre de Tennis de Table par équipe :

Mon objectif… est de créer un service web permettant de :

  • saisir d'une manière conviviale une feuille de match
  • partager facilement une feuille de match sur le web
Là où Ember.js est intéressant dans cette application web, c'est qu'il y a beaucoup d'intéraction au niveau des champs de la feuille de match.
Par exemple, lors de la saisie des noms des joueurs dans les deux cadres en haut du document… ces noms sont automatiquement mis à jour dans la liste des matchs.
Le total des sets… des matchs doit être automatiquemnt mis à jour lors de la saisie des scores des sets.

Code source et démonstration de l'application

Voici une démonstration de la première version de l'application. Pour le moment il n'y a qu'une petite partie de l'application Javascript qui est réalisée.

Je ferai un screencast de la démonstration pour le prochain billet.

Par la suite… je vais mettre à jour ce billet pour qu'il continue à être à jour avec les évolutions de l'application… du code source…

Read and Post Comments

Réflexions à propos de NodeJS et de Javascript plus globalement

Cela fait quelques jours que je me pose la question suivante : « Est-ce que Node.js ne va pas devenir une technologie incontournable / majeur dans les 2 ans qui viennent ? »

Le contexte

Je suis un développeur Python depuis de nombreuses années. J'aime ses librairies, j'aime ses outils, j'aime sa communauté.
J'aime tellement sa syntaxe que quand je vois la syntaxe d'autres langages, j'ai une réaction quelque peu épidermique à la lecture du code.
Avec le temps, l'habitude de la syntaxe Python minimaliste proche d'un pseudo code rend difficile la possibilité d'apprécier un autre langage. Je ne sais pas si c'est positif ou négatif, je me pose simplement la question. Enfin ceci est un autre sujet.

Cependant, mon regard se tourne de plus en plus vers Node.js... je n'ai pas franchi le pas, je n'ai rien développé en Node.js… mais je me demande si je ne passe pas à coté de quelque chose d'important.

Les forces de Node.js

  • Bien que Node.js date seulement de 2009 :

  • tous les développeurs web (front-end) connaissent le langage, il est très populaire. Par conséquent, pour passer à Node.js il n'y a pas le frein d'apprendre un nouveau langage comme ça serait le cas avec l'utilisation d'un framework web basé sur Ruby ou Python. Je pense que dans les mois qui viennent, de nombreux développeurs PHP vont passer à Node.js… surtout ceux qui regardaient ailleurs mais qui ne souhaitent pas apprendre un nouveau langage.

  • la possibilité de partager du code (librairies communes…) entre la partie client et serveur peut être intéressant. La question se pose de plus en plus étant donnée qu'on est de plus en plus amené à effectuer beaucoup de traitement coté client (exemple avec Backbone.js).
    Dernièrement, dans tous mes projets de développement web, j'ai utilisé un moteur de template coté client en plus du moteur de template coté serveur.
    Je dois gérer de plus en plus souvent une couche modèle coté client. Des vues coté client… Cela fait donc plein d'éléments en doubles, utilisés une fois sur le serveur, une fois sur le client. Donc deux technologies à maîtriser.
    Ces derniers jours, la visualisation du screencast du framework javascript Meteor m'a mis la puce à l'oreille.
    Autre exemple, il est possible d'utiliser la même API Canvas coté client et coté serveur (avec node-canvas).
  • Node.js semble être très rapide, ça tient très bien la monté en charge.

  • La vitesse de l'interpréteur Javascript est en constante progression V8 (JavaScript engine)

Faiblesses de Node.js

Je ne sais pas si mes remarques sont exactes, je n'ai aucune expérience en Node.js.

  • Exemple dans la partie Bad Use Cases du guide Felix's Node.js Convincing the boss guide il est indiqué que les framework Node.js sont moins matures que ce que l'on peut trouver en Ruby, Python et Php (bon pour ce dernier j'ai des doutes, je pense que la communauté Node.js est déjà plus mature, plus structurée que la communauté Php… enfin bon…).
  • Je ne pense pas que Sequelize soit aussi mature que SQLAlchemy
  • Je n'ai pas trouvé d'outil comme Whoosh en Javascript (c'est un moteur de recherche léger). J'ai tout de même trouvé Node-xapian

Je ne sais pas si il est encore tôt pour passer à Node.js mais si la communauté continue à être aussi dynamique que ces 2 dernières années… alors les pièces manquantes seront bientôt créées.

Est-ce que l'on va retrouver Javascript partout ?

Voici une petite liste :

Quand je vois cette liste, je me pose sérieusement la question : est-ce que Javascript est le langage incontournable de ces 10 prochaines années ? Certes il est déjà incontournable dans le navigateur, mais pour le reste ?


Édition 5 mai 2012 :

  • j'ai publié ce billet sur LinuxFR, j'ai reçu 90 commentaires…
  • j'ai publié ce billet sur la mailing list de l'Afpy, j'ai reçu 25 commentaires… malheureusement les archives de cette liste n'est pas publique

merci beaucoup pour vos retours d'expériences !

Read and Post Comments

Astuce pour filtrer ses propres visites dans Google Analytics

Pour ne pas fausser le nombre de visites de mes sites - c'est à dire des sites sur lesquels je suis en train de travailler, développer, rédiger du contenu - je cherchais une astuce pour que Google Analytics ne prenne pas en compte mes propres visites.

J'ai trouvé par exemple une solution qui constite à mettre en place un filtre sur les adresses IP que j'utilise. Cependant, cette solution ne me convient pas tout à fait. Je peux consulter mon site depuis divers accès… je n'ai pas envie d'ajouter toutes les adresses IP.

J'ai trouvé une autre solution qui me convient mieux :

  • je modifie le user-agent de mon navigateur, j'y ajoute un identifiant
  • dans les pages de mes sites, j'active le code Javacript de Google Analytics uniquement si le "User-Agent" ne contient pas l'identifiant que j'ai ajouté

Pour modifier la valeur de mon "User-Agent", j'utilise l'extension Firefox User Agent Switcher.

J'ai ajouté "stephane-klein" comme identifiant, ce qui me donne le résultat suivant :

Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2;stephane-klein) Gecko/20100101
Firefox/10.0.2

Ensuite, au niveau de l'activation de Google Analytics dans mes pages webs, j'ai quelque chose comme ça :

if (navigator.userAgent.indexOf("stephane-klein") == -1) {
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'UA-29999662-1']);
    _gaq.push(['_trackPageview']);

    (function() {
    var ga = document.createElement('script');
    ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
    'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(ga, s);
    })();
}

Certes, mon identifiant "stephane-klein" sera visible pour toutes mes visites sur tous les sites (bien que je peux switcher rapidement la valeur de mon "User-Agent") mais bon, je trouve cela pas bien grave. Il est aussi possible d'utiliser un identifiant qui n'a pas de sens, un UUID par exemple.

Read and Post Comments

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
« Billets plus récentsBillets plus anciens »

Mes flux :