Bonsoir,

Le temps m'a manqué en décembre pour finir comme  je le voulais le raisonnement de mon dernier billet. Y revenir longuement aurait des airs de "réchauffé" donc je ne vais pas relancer le débat Features/Patterns d'autant que j'ai dit l'essentiel dans les réponses aux commentaires qui ont été faits. Fondamentalement, ce que je ne parviens pas à comprendre dans Features c'est l'intérêt de mettre une couche entre le core et un module, puisqu'une feature est un module - pourquoi ne pas coder directement le module ? Un intérêt possible, ceci dit, serait dans le cas où vous voulez donner à un utilisateur la possibilité d'activer à volonté des fonctionnalités "grand public" sans lui donner l'accès à l'administration des modules proprement dite. Ce peut être très pratique dans une plateforme de type multiblog, où chaque blogueur pourrait activer ou pas, par exemple, un agenda ou un gestionnaire de "galerie" d'images sur son blog.

En dehors de cela, je m'intéresse davantage à Patterns car ma pratique professionnelle de Drupal me le ferait utiliser plutôt pour des sites d'un petit nombre de types (en clair, plusieurs sites en grande partie semblables dans leur fonctionnement). J'aurais donc besoin de gagner du temps sur l'installation et la configuration d'ensemble plus que sur une fonctionnalité en particulier. Raison pour laquelle je garde également un oeil sur les profils d'installation, rendus encore plus intéressants avec l'annonce faite au début du mois (Fully packaged Drupal distributions now deployed on drupal.org). Jusqu'à présent, pour utiliser un profil d'installation, il fallait charger séparément :

• la dernière version du coeur de Drupal
• le profil
• la dernière version de tous les modules nécessaires pour le profil

Désormais les créateurs de profils peuvent proposer des packs complets ; on mesure l'intérêt de la chose ! On peut gager qu'ils vont probablement se multiplier.

Pour autant, la question plus profonde est celle du rapport entre généricité et spécificité : en clair, à partir de quand le besoin auquel répond un travail personnel (configuration de différents modules, ou développement personnel) est-il suffisamment générique pour que le partage de mon travail soit pertinent ? Jusqu'à quel point une fonctionnalité avancée est-elle transposable d'un site à l'autre ? Plus le produit que vous proposez est élaboré, moins largement il sera utilisable.

C'est une question plus générale à Drupal dans son ensemble : en témoigne le débat sur le "framework" et le "product". Le succès de Drupal tient à ce qu'il peut constituer une base de travail pour de très nombreux projets. Au risque de surprendre le nouveau venu, plus habitué à des produits plus "finis", quand il découvre l'aridité de la distribution de base. On peut tout faire avec Drupal, mais avec Drupal tout seul on ne fait pas grand'chose, et il faut pas mal de travail pour obtenir quelque chose. C'est la raison pour laquelle sont apparues les distributions, comme les profils d'installation. Un profil d'installation est encore une solution assez simple, mais vous pouvez trouver des propositions autrement plus élaborées (je pense à Open Atrium, Tattler, etc.). Le risque ici est que chaque distribution s'éloigne petit à petit du noyau, en suivant sa logique propre. C'est un risque dont Dries Buytaert parait bien conscient, comme le montre cet article d'il y a déjà trois ans. Il a récemment annoncé que le développement de Drupal 8 se concentrerait plus particulièrement sur cette dichotomie entre le "framework" et le "product", avec deux "co-maintainers" responsables de chacune de ces orientations. Le dilemme est clair à exprimer : comment conserver une base légère et flexible tout en répondant à la demande accrue d'un produit qui soit un minimum abouti. Demande accrue par la popularité grandissante de Drupal. La suite de l'histoire de Drupal dépendra de la capacité de la communauté à trouver une réponse cohérente à cette question.

Je vous souhaite un joyeux réveillon et vous donne rendez-vous en 2010 pour de nouvelles aventures drupalistiques !