Derrière cette étape avec un nom un peu présomptueux, je veux tenter d’expliquer la philosophie de ce CMS. Je ne vais pas rentrer dans les détails techniques qui ne sont pas le but de ce billet. Il y en aura d’autres pour effectuer cela.

Si je tiens à le faire c’est parce qu’Orchard malgré son apparente complexité pour l’aborder, il est finalement assez simple de l’étendre bien plus que sur d’autres CMS et ce encore plus si on prend le parc des CMS développé sur les technologies de Microsoft.

J’étais jusqu’à présent surtout habitué des CMS du type Joomla, Xoops et compagnie. Ils sont intéressant, mais souffre d’un gros défaut. Ajouter une nouvelle fonctionnalité prend du temps, mais en plus il est parfois difficile de la faire cohabiter avec d’autres modules voir même avec le noyau du CMS sans faire des hacks très moche. Avec bien sur les complications que cela apporte, lorsqu’il y a une évolution du noyau du CMS… On perd les hacks, il faut les refaire voir si le noyau change alors il faut carrément repenser carrément tout le module développer. Sans parler des contraintes de gestion de bases de données, etc.

Orchard dans ce contexte change beaucoup la donne et offre même de nouveaux outils finalement assez bien foutu. Certes, il faut un niveau technique de plus haut niveau pour bien l’appréhender car on fait appel aux bonnes pratiques, mais aussi aux dernières nouveautés qu’offre le Framework 4.0 avec des types dynamiques qui fait une sacrée force d’Orchard. Flûte je sens que j’ai l’impression que vous avez le sentiment que je vous aurais mentis… Non, j’arrête là sur l’aspect « technique ».

 Orchard est novateur dans sa façon de penser le CMS. Du moins sur l’expérience que j’ai eu jusqu’à maintenant des CMS. Les choses ont peut-être changé sur d’autres technologies. Orchard, arbore les pages web comme un agrégat de morceaux de contenu. Ainsi à partir d’une uri, on va savoir quel agrégat on va afficher, modifier, effacer, etc. Je vous ai encore perdu, je le sens.

Je vais être plus concret :

Un blog, c’est une notion classique et qui est très bien utilisé pour démontrer cela sur la documentation du projet Orchard. Un post d’un blog qu’est ce qui le représente ?

• Une route (url)
• Un titre
• Une date de publication
• Du texte
• Des tags
• Des commentaires

Ainsi Orchard découpe la représentation avec la liste de ces morceaux. La représentation d’un billet de blog revient à représenter un « content type » de type « blog post ». Et un blog post c’est un contenu représentant l’agrégat des éléments d’informations cité ci-dessus. Mais on pourrait très bien pu rajouter, d’autres champs si cela nous fait plaisir…

Toute la force d’Orchard est là. Il n’est pas nécessaire de passer par l’écriture de code pour ajouter un morceau de contenu (enfin s’il a déjà été défini). Ainsi, on peut rajouter des coordonnées géographiques à un post, ou encore des notes, etc. Là on profite réellement de quelque chose de modulaire. Et le rendu du titre, étant développé dans le noyau du CMS, on a plus à récrire la gestion du titre, on en hérite automatiquement. Tu te dites, et si je ne veux pas le rendu par défaut du titre ? Et bien on surcharge alors le rendu du titre au sein de son module… ou du Thème via un rendu alternatif en son sein.

L’inconvénient de cette approche, c’est lors du développement d’un module. Lorsqu’on n’est pas très familier par cette démarche, tu perds le nord facilement, surtout avec les habitudes classiques que l’on prend en créant des sites web en MVC avec l’implémentation de Microsoft. Mais également avoir de bonnes connaissances en termes d’architectures car beaucoup de concepts sont implémentés bien pensées sont implémentées.

Mais là on a vraiment un découpage très clean entre fonctionnalités, accès à la base, gestion en ligne de commande (oui c’est possibleJ), représentation graphique, etc. Et une fois développé on active ou non les fonctionnalités, on en fait des agrégats ou pas etc.

Ce qu’il faut retenir, c’est que quasiment tout le CMS est modulaire. Une extension, peut elle-même être étendue. Je trouve cela assez impressionnant et c’était souvent un point très frustrant sur les CMS que j’ai eu l’occasion de manipuler. Une extension donnée était adaptée pour répondre à un besoin donné. Mais pour un besoin similaire avec seulement quelques point de divergences pouvait rendre caduque son utilisation et imposait l’écriture d’une autre extension pour finalement un gain très minime en soi. Ce n’est plus le cas avec Orchard.

Ainsi avec ces petits tutoriaux, le but est de montrer les étapes à suivre pour rendre cela possible, et les difficultés que j’ai rencontrés afin d’aider la communauté pour améliorer la documentation entre autres, et te donner des pistes à toi futur développeur de modules/thèmes qui te permettront j’espère les déboires que j’ai rencontrés...