Ceux qui ont suivi un petit peu le lancement du projet Open atrium ( http://openatrium.com/ ) auront sans doute entendu parler du fameux trio de modules context,spaces et surtout features ; sur lequel s’appuie OpenAtrium.

Comme il existe encore peu de documentation à ce sujet voici un bref aperçu de ce qu’est features pour permettre une première approche à ceux qui se demandent à quoi ça peut bien servir et comment commencer à créer ses propres features. N’hésitez pas à corriger mes approximations, ayant découvert depuis peu cette possibilité je suis loin de la maitriser.

Un peu de théorie

Features peut être considéré comme une «nouvelle couche de drupal». Jusqu’ici on pourrait théoriser Drupal comme étant constitués en 3 niveaux principaux.

1. PHP  : le langage dans lequel est codé Drupal
2. API de Drupal  : codée en PHP, elle offre une librairies de fonctionnalités facile à manipuler.
3. Module  : Batis sur l’API, ils permettent de répondre à un certain besoin utilisateur. Ce niveau est le plus facile à manipuler puisqu’il nécessite pas de connaissances en php pour être mis en place.

Pour la construction du site, il faut très souvent combiner plusieurs modules ensemble afin de répondre à un besoin utilisateur encore plus large que celui auquel peut répondre un module. Par exemple une combinaison des modules CCK, views, node peut permettre d’offrir aux membres d’un site la possibilité de consulter des petites annonces et d’en poster.

Mais en regardant votre administration de Drupal, rien n’indique que tels champs CCK + telles views + tels blocs sont en réalité les éléments constituants une mini-application (gestion de petites annonces sur un site). Vous êtes le seul à le savoir au fond.

Une autre approche avec Features

Le module Features se propose donc d’ajouter un nouveau niveau à Drupal, qui ressemble alors à ceci

1. PHP
2. API
3. Modules
4. Features

Features permet de prendre une «photographie» des différents éléments et modules permettant de construire une «macro-fonctionnalité» telle que la gestion de petites annonces sur un site ; et de l’exporter sous la forme d’un module. En clair, vous lui indiquez quels éléments permettent de construire votre macro-fonctionnalité (tels champs CCK, + telle ou telle vue, + tel ou tel bloc) ; et vous pouvez exporter tout ça sous forme d’un module que vous pourrez directement activer la prochaine fois !
Ce module contiendra des dépendances comme tout module vous indiquant quels modules vous devez installer pour qu’il fonctionne, et il se chargera lui même de recréer les vues , champs CCK etc… nécessaires au fonctionnement de votre mini-application.

Le plus incroyable c’est que cela marche ; mais attention, cela ne marche pas avec tous les modules : sont supportés actuellement CCK, context, Views, ImageCache et Menu. Ce qui permet déjà de concevoir de très jolis features.

Spaces

La notion d’espace est très liée à celle de feature : une feature peut être activée, désactivée pour un espace particulier : ainsi si vous utilisez organic groups + spaces, vous pouvez proposer à chaque groupe d’activer ou de désactiver des features selon leur besoins, et cela indépendamment des autres types de groupe. Open atrium fonctionne principalement avec des espaces pour les organic groups et apparemment pour les profils (user-spaces).

Physiquement, la notion d’espace est en fait liée au module «purl» qui permet d’ajouter un préfixe à vos url. Ce préfix permet de déclencher l’espace et tous les paramètres de context ou des vues qui peuvent être sensibles aux espaces. (il me semble d’ailleurs que c’est le module Purl qui préfixe les urls dans le module d’internationalisation i18n).

exemple : avec user-space, l’url de votre compte devient «space-votrepseudo/user».

La notion d’espace est toute indiquée pour la gestion d’un intranet en particulier et a probablement été spécifiquement conçue pour ce besoin particulier.

Context

Context est un module permettant de facilement regrouper des éléments de configuration d’une feature. Exemple concret : si vous voulez faire une feature de blog, vous souhaitez que fasse partie de votre feature :
- une vue listant vos derniers billets
- un bloc listant les derniers commentaires
- que ce bloc apparaissent sur les types de contenus blogs et peut être aussi sur la vue

Qui n’a jamais révé d’expliquer par exemple simplement à Drupal que la vue listant vos types de contenu news fait partie de la même section du site que vos node news ? Et qu’il est en conséquence logique que votre item de menu «news» soit en surbillance quand vous vous trouvez sur la page de liste de news ? C’est typiquement ce genre de problématique à laquelle s’attaque context.

Context est un module permettant de centraliser et d’exporter tous ces paramètres de configuration et donc devient un élément clef pour composer votre feature. En général, pour composer votre feature vous avez besoin d’un contexte permettant de choisir quel blocs et vue font partie de votre feature, comment ils sont positionnés (plus d’autres paramètres intéressants proposés par context). Nulle obligation de passer par contexte, mais cela facilite la construction de votre feature.

Vous pouvez ensuite exporter dans la feature (en créant la feature dans le menu feature) en prime bien d’autres choses intéressantes comme un type de contenu, des champs CCK, un élément de menu, une permission utilisateur etc…

Impact sur votre workflow de production

La feature va donc mémoriser et regroupe dans un module tous un tas de paramètres de configuration normalement éparpillés dans la base de données. avantages certains :
- meilleur lisibilité d’ensemble de votre site. On peut retrouver facilement ses petits et voir quels modules concourent à quel fonctionnalités sur le site.
- mise à jour possible sans écraser la BBD, simplement en mettant à jour le fichier php de votre feature ! Cela permet de résoudre un probleme majeur du workflow de production avec Drupal qui oblige à écraser la base de données (et donc le contenu qui va avec…) pour mettre à jour les paramètres de configuration.

Inconvénients  :
- Tous les modules ne permettent pas d’être capturés par features ; et cette logique de feature ne fait pas partie de la logique du coeur de Drupal. Ca reste donc une solution intéressante mais pas pleinement implémentée et fonctionnelle dans Drupal. Les modules doivent notamment implémenter certains hooks pour être découverts par context et disposer d’une configuration exportable/importable en php (comme le module views possède cette possibilité d’export) ; ce qu’ils ne proposent pas tous.

Ressources (anglais seulement, désolé ! )

• http://developmentseed.org/blog/2009/may/29/making-and-using-features-dr…
  Vidéo montrant pas à pas la construction d’un feature.

• http://affinitybridge.com/blog/features-abridged

• http://developmentseed.org/blog/2009/jan/28/spaces-paradigm-reusable-dru…