Comparaison du module patterns et du module features

N'hésitez pas à corriger les informations données ici , je n'ai pas la prétention de faire une véritable comparaison définitive, je donne simplement des pistes de réflexions pour ceux qui hésitent entre les deux.
Cet article ne demande qu'à être amélioré et ajusté par ceux qui connaissent bien le module patterns.

Vous trouvez en fichier attaché au bas de l'article un petit tableau comparatif, surement incomplet pour l'heure

http://drupalfr.org/sites/default/files/comparatif.png

Vous pouvez téléchargez le module patterns ici.
http://drupal.org/project/patterns

Notez enfin qu'il est tout à fait envisageable d'utiliser à la fois patterns et features en même temps sur un site selon le type de routine à automatiser.

Introduction

Patterns est un module très intéressant et ingénieux permettant d'écrire un fichier xml qui permettra, à son import, de configurer automatiquement des pans de votre site avec des informations de configurations très poussées. En rédigeant votre code xml (ou yaml ou php), vous pouvez créer des types de contenus, des champs CCK, des presets image cache, des nodes, des blocks, de la taxonomie, des utilisateurs. Son champ d'action est très large et le degré de précision impressionant. Je vous conseille vivement de lire l'article suivant sur drupalistic pour d'autres renseignements et un exemple sympa de pattern:
http://www.drupalistic.net/module/patterns

Comment fonctionne pattern ? exemple

Pour faire fonctionner pattern, nous devons rédiger un document xml que nous importerons ensuite dans l'administration du module patterns. Un pattern (et le fichier xml) est divisé en trois gande parti : description du pattern, modules requis, actions à effectuer lors qu'on lance le pattern.

cas utilisateur : nous voulons créer automatiquement un type de contenu news, en y ajoutant un champ image field.

La description de notre pattern

Ces quelques lignes permettent de décrire notre pattern. Ils sont indispensables.

Les modules requis pour le fonctionnement de notre pattern

Maintenant on doit réfléchir aux module dont nous avons besoin : dans mon cas utilisateur je veux utiliser une champ image avec image field et controler la retaille d'image avec image cache. Image cache dépend de image api, image field dépend de file field et de content. On va aussi inclure le module Image cache UI pour pouvoir retoucher dans une interface utilisateur nos presets au besoins.
J'insére ceci juste après la balise de fermeture , pour déclarer les dépendances à activer :

Les actions de notre patterns

On entre dans le vif du sujet. Créeons notre type de contenu « news ». Toutes nos actions devront être placés entre les balises actions. Je donne le nom machine et humain du type de conteu, je précise que je veux activer les commentaires, ne pas activer l'upload, que les news soient publiées par défaut, et que ce type de contenu ne soit pas promu sur la page d'accueil.

Si on lance notre pattern, tout fonctionne à merveille et le type de contenu se crée à la perfection. Rédiger un type de contenu s'avère donc un jeu d'enfant. Comme patterns utilise l'API des formulaires de Drupal, on peut controler absolument n'importe quel paramètre du type de contenu : nombre de commentaires par page, type de commentaire,etc, etc.... Avec le module features, nous aurions eu besoin d'implémenter un hook dans le fichier .module pour pouvoir affiner les réglages des commentaires, de l'upload et du status de publication.

Rajouter un champ CCK

Nous sommes toujours au seins des balises actions . J'ajoute un champ filefield avec l'option « image » que me confère le module image_field, je décide que 5 images sont autorisées par article

Si on veut rajouter de la taxonomie, des presets d'image cache , des nodes, des blocks ?

La syntaxe pour tous ces objets sera tout aussi facile à rédiger, et la finesse de configuration toujours aussi pointue. Même si les premières fois il va falloir réfléchir et tatonner pour trouver les bon noms de paramètres pour le xml.

Comment créer une vue avec pattern?

A compléter : je n'ai pas eu le temps de comprendre comment créer une vue avec patterns. Une chose est sure, sur ce point, le module features a un énorme avantage car il permet d'exporter des vues et de les incorporer à notre feature en un seul clic: tandis que patterns, de par le fonctionnement du module, va vous demander de remplir de nombreuses informations pour reproduire une vue. Features à un très sérieux avantage pour l'instant de ce côté puisqu'il permet en un clic d'exporter une vue en profitant de l'API d'export de views.

Quelle sont les différences entre features et patterns ?

Ils ont un objectif commun : pouvoir réutiliser sur un nouveau site les configuration de modules patiemment créer sur un autre site. Mais pour cela ils utilisent une méthode très différente :
- Patterns s'appuie sur l'API des formulaire de Drupal. C'est à dire qu'à partir du xml que vous lui fournissez, il va soumettre programmatiquement les formulaires de configuration tout comme si vous le faisiez vous même. A part qu'il va beaucoup plus vite que vous :-). Vous obtenez donc le même résultat que si vous aviez fait tout ce travail à la main.

• Features agit d'une manière différente : il s'appuie sur l'API d'exportation des modules pour exporter leur configuration puis stocker cette configuration dans un fichier. Il extrait finalement les données présentes dans la base de données pour les mettre dans un module. Ce module devient ensuite un "donneur d'ordre" : il dit à image cache ou à CCK de créer telle ou telle chose, mais si on désactive la feature, tout disparait.

Exemple concret de cette différence : un type de contenu importé par patterns sera enregistré dans la base de données tout comme si vous l'aviez créer vous même à la main. Vous aurez un bouton delete vous permettant de l'effacer. Tandis que le type de contenu sauvegardée par feature sera contenu dans le fichier du module. Le type de contenu n'apparait que si vous activez la feature, vous n'aurez pas de bouton "delete" car ce type de contenu ne sera pas stocké dans la base de données. En revanche tous les élements créer par feature disposerons d'un bouton "revert" permettant de retourner à la configuration originelle donnée par votre feature.

Les avantages de patterns

• un large champ d'action et de possibilité. Un haut degré de précision. Pour en faire autant avec features, vous devrez installé le module strongarm et implémenté un hook_strongarm dans le fichier .module de la feature.

• possibilité de créer des vocabulaires, des termes, des nodes, des utilisateurs, des roles. Feature ne le fait pas de base. Patterns semble également très souple sur la gestion des blocs.

• L'idée de s'appuyer sur l'API des formualaire est ingénieuse : cela permet virtuellement de pouvoir s'adapter à n'importe quel module.

• La possibilité d'imbriquer des patterns dans des patterns. Cela permet sans doute de faire des features plus « configurable ». on peut imaginer un pattern qui créer le type de contenu news, le bloc, les tags, sans créer les images avec leurs presets. Ces images pourraient être un autre pattern que l'on peut selon nos besoin inclure ou pas dans notre pattern. On peut donc faire des patterns de patterns. :-)

• intégration avec pathauto

• Tout au même endroit :-) Tout se trouve exclusivement dans le fichier xml (ou autre format) sans une goutte de code php. Cette homogénéité est plaisante.

• j'en oublie surement, libre à vous d'éditer cette liste.

Les inconvénients de patterns

• Aucune interface utilisateur pour générer automatiquement votre xml. La page d'administration du module est actuellement incomplète, ne permettant pas de supprimer ( ou de désactiver un pattern ). (en tous je n'y suis pas arrivé)

  il est donc beaucoup plus long d'écrire un pattern en xml, et cela demande beaucoup plus de rigueur, que d'utiliser features qui permet parfois en quelques clics de faire quelque chose d'équivalent.

• Exporter une vue et ses blocs semble laborieux alors que features peut réaliser cela en un clic.

• Pas de bouton « revert » pour l'instant comme sur features, permettant de revenir à l'état antérieur du pattern

• Pas de possibilité de désactiver un pattern comme on désactive une feature.

Avis subjectif : Pourquoi je préfère features malgré sans champ d'action apparemment plus réduit

• Grande facilité pour importer des vues et leurs blocks

• Contrairement à patterns ou on doit rédiger de zero, features requiert simplement que vous créeiez comme à votre habitude vos types de contenus etc... puis vous n'avez qu'à exporter pour obtenir votre feature.

• Pouvoir utiliser le module context.

• Utilisation possible de features avec le module spaces, même si je n'ai pas encore exploré cette partie. Mais bon, cela donne open atrium :-)

• Chaque élément fourni par une features (views, preset d'image cache, champ CCK) dispose d'un bouton « revert ». Si vous n'etes pas satisfait des nouvelles évolutions apportées à votre features, le bouton revert permet en un clic de retrouver l'état orignel de votre vue, de votre champ CCK ou même de toute votre feature.

• facilité de mise à jour : il suffit d'uploader un fichier, et en cas de pépin il suffit de réuploader une version précédente du fichier, nous n'avons pas à nous préoccuper de la base de données. Patterns est plus « barbare » : il éxécute des requetes sql et il me paraît donc IMPERATIF de faire un back up and migrate avant tout import d'un nouveau pattern. Or, c'est justement pour éviter de devoir faire des backups constant au moindre changement de la base de données que je suis intéressé par features.

• En tant que développeur PHP, features me permet d'implémenter mes propres hooks en additions de la features, cela me donne donc une liberté totale, je ne suis dons pas frustré de certaines limites de features par rapport à patterns.

• une certaine confiance en Development Seed : j'aime leur travail de réflexion sur Drupal et les solutions qu'ils apportent. A priori features me parait promis à un plus bel avenir que patterns, mais je peux être dans l'erreur.