Blog

DrupalCon Amsterdam - Episode 2 : Etat des lieux sur Drupal Commerce 2019

Nono
08/11/2019
Toujours dans le sujet de la dernière DrupalCon qui s'est déroulée à Amsterdam en octobre dernier, focus sur l'actualité de Drupal Commerce.
Drupal Commerce

ROAD MAP

» Voir la vidéo de la conférence : https://www.youtube.com/watch?v=bSeG7YTCvks

Ryan Szrama, fondateur et CEO de l'entreprise Commerce Guys, maintenant renommée Centarro, est à l’origine du projet d’e-commerce le plus célèbre de Drupal. Au cours d'une conférence intitulée  "Taking Drupal Commerce to Market: 2019 Roadmap", il a fait le point sur l'avancement du projet Drupal Commerce.

Drupal Commerce offre avant tout un framework complet pour la construction de plateformes d'e-commerce. Et à la différence de ses concurrents (comme par exemple WooCommerce), cette nouvelle version a vraiment été pensée dans son ensemble (de manière "holistique") pour pouvoir s'adapter à tous les cas possibles. Et bien qu'atteignant un niveau de qualité et de flexibilité comparable (voir supérieur) à ses concurrents les mieux notés, la solution reste (et restera) complètement gratuite et Open Source.

Par ailleurs, l'e-commerce découplé est en pleine expansion et Drupal Commerce possède plusieurs avantages distinctifs par rapport à ses concurrents :

  • Pas de coût de licence
  • Une communauté active et expérimentée
  • Une flexibilité du framework
  • Une possibilité de construire des processus de paiement sur-mesure
  • Une gestion innée de l'internationalisation

Pourtant, malgré tous ses avantages et de multiples "success stories", Ryan nous rappelle que Drupal Commerce n'est pas souvent évoqué dans les conversations quand vient la question de savoir "quelle solution d'e-commerce choisir ?".

Les raisons à ce manque de visibilité sont multiples, mais la principale cause est l'avantage que possèdent les plateformes concurrentes d'avoir une voix faisant autorité derrière leur application, entraînant une bien meilleure promotion de la solution. Et cela que soit pour les études de cas mises en avant, la définition et mise en place de stratégies de marketing, ou même l'établissement clair et simple d'une roapmap pour le développement de nouvelles fonctionnalités. C'est un peu le revers de la médaille de l'Open Source !

 

Malgré tout, les efforts pour améliorer la solution continuent à un rythme encourageant :

  • Le module Commerce Address Book est finalement prêt. 

  • Dans la prochaine version, la prise en charge des différents taux de TVA sera en place.

  • Le module Commerce Invoice sera bientôt opérationnel et permettra une gestion complète de la facturation.

  • L'intégration de plateformes de paiement (Paypal, Stripe, etc) continue, notamment dans le cadre du respect de la réglementation européenne (EU PSD2).

  • Le support pour le module Commerce Reports est étendu par NY MEDIA. Nous devrions avoir de "jolis graphiques" à disposition bientôt, le reporting étant un élément clé du e-commerce.

  • La société "éditrice" Centarro met en place un véritable service de support professionnel pour Drupal Commerce (avec abonnement payant), afin que les utilisateurs trouvent plus facilement réponses à leurs questions.

  • La mise en place d'une roadmap claire pour l'ensemble de l'ecosystème. Vous pouvez la découvrir via ce lien : https://www.drupal.org/project/commerce/issues/2913801

  • Faciliter l'évaluation pour de nouveaux utilisateurs

    • Un "project template" est disponible pour composer. Il est ainsi possible d'installer un nouveau Drupal Commerce en une ligne de commande.

    • Dans le cadre d'un partenariat avec Nerdstein, il est désormais possible d'avoir une démo de Drupal Commerce en quelques clics et minutes sur simplytest.me.

 

Et pour finir, une des bonnes nouvelles est que Drupal Commerce 2 est déjà prêt pour Drupal 9 (qui sortira en juin 2020, dans 8 mois). Cela sera rendu possible grâce à la nouvelle stratégie de la communauté pour rendre plus simple les mises à jour pour les prochaines versions majeures (voir notre précédent billet de blog à ce sujet). Cette nouvelle peut paraître banale mais pour tous ceux qui ont connu l'expérience de la migration d'une solution d'e-commerce sous Drupal vers une nouvelle version majeure, c'est une grande bouffée d'air frais de savoir qu'il ne va pas falloir tout reconstruire encore une fois.

Pour rappel le passage de Ubercart à Drupal Commerce V1 (en Drupal 7) aura pris trois ans. Quant au passage de Drupal Commerce V1 à cette nouvelle version, elle aura également pris 3 ans.

 

    Drupal commerce : Qu'est ce qu'il y a sous le capot ?

    » Voir la vidéo de la conférence : https://www.youtube.com/watch?v=gknvo8-Hkkw

    » Voir les slides de la conférence :http://presentations.robiningelbrecht.be/drupalcon-amsterdam-2019/

    Lors de cette conférence Robin Ingelbrecht nous présente comment manier Drupal Commerce en tant que Framework. 

    Comment ajouter une étape dans le tunnel de commande ? Comment appliquer un cout d'expédition automatique si un produit possède une condition particulière ? Comment appliquer une réduction automatiquement si le panier dépasse un seuil (en montant et/ou en quantité de produits) ?

    Toutes ces questions, et bien d'autres encore ont leurs réponses dans cette présentation, qui est l'une de nos favorites de ce DrupalCon. Il s'agit du tutoriel parfait pour tout développeur backend commençant à mettre les mains dans la nouvelle version de Drupal Commerce.

     

    Conclusion

    Pour notre part, nous sommes plutôt enthousiaste par ce qu’apporte cette nouvelle version de Commerce. Elle est vraiment bien pensée en tant que Framework d’Ecommerce complet. En effet, tout est facilement implémentable, car il est possible de créer des plugins pour tous les cas (cf : plus haut la conférence de Robin Ingelbrecht). Pas de question de comment on va devoir tordre le système pour pouvoir répondre aux besoins du projet. Et la maintenance sur le long terme se promet déjà beaucoup plus simple et rapide que pour celle en Drupal 7. Enfin, avec les modules Invoice, Reports, et AdressBook, le framework est “complet” (ou quasiment).

    Néanmoins cette flexibilité vient avec un coût, celui de la complexité et du temps nécessaire pour comprendre l'outil quand on le découvre. Mais c'est là un peu la nature même de Drupal, sa principale force et faiblesse depuis toujours.

    Comme l'a résumé Dries Buytaert récemment, "Drupal est fait pour les projets digitaux ambitieux".  Cela signifie souvent pas mal de complexité, avec des besoins et des développements sur-mesure. Et malgré les meilleurs efforts, cela reste la responsabilité du développeur de faire attention à ce qui se passe.

    La principale difficulté que rencontre Drupal Commerce est en fait le passage de Drupal 7 à 8. Il nécessite parfois une véritable ré-écriture de modules, en plus de mises en places des processus de migration de contenus. Tout cela engendre un coût et réduit donc les chances de voir un client accepter de continuer à utiliser un CMS pour lequel la maintenance engendre un tel coût... A nous de lui faire changer d'avis en démontrant que cet investissement est payant sur le long terme !

    DrupalCon Amsterdam - Episode 1 : Drupal en route vers sa version 9

    Nono
    01/11/2019
    Du 28 au 31 octobre dernier, avait lieu l'événement incontournable de la communauté Drupal : la convention DrupalCon Amsterdam 2019. Et comme chaque année depuis plus de 10 ans, l'équipe d'Axess Open Web Services était présente.
    Drupal arrive à la fin de sa version 8, et n'est plus qu'à 8 mois de sa prochaine version majeure. Retour sur les évolutions à venir de notre CMS préféré !
    DrupalCon Amsterdam 2019

    La convention DrupalCon Amsterdam 2019 vient de s'achever. Comme chaque année depuis plus de 10 ans, l'équipe Axess Open Web Services était (bien !) présente. Cette année, c'est Stamatia, Didier et Pierre qui ont eu la chance de pouvoir y participer. Retour sur 4 jours 100% Drupal !

    Un moment incontournable de toute DrupalCon qui se respecte est bien entendu la présentation d'ouverture "keynote" (appelée Driesnote) de Dries Buytaert, le fondateur de Drupal. Ce dernier nous a ainsi confirmer que Drupal arrivait à la fin de sa version 8, et que nous ne sommes plus qu'à 8 mois de la sortie ("release") de sa prochaine version majeure.

    Voici un bref résumé des évolutions à venir de notre CMS préféré que nous avons pu entrevoir à cette conférence.

     

    Les dernières améliorations de Drupal 8

     

    • Drupal automatic update

    Il s'agit d'un module permettant de mettre à jour les modules contribués d'un site Drupal, et même le core, tout cela via l'UI (Interface Utilisateur), c'est-à-dire sans passer par le terminal ou le code source.

    Cette fonctionnalité est assez intéressante, et nous sommes d'ailleurs en train de travailler sur quelque chose de similaire en interne chez AOWS, mais il est trop tôt pour en dire davantage. Pour en savoir plus, surveillez nos prochains billets de blog ! :)

     

    • Claro

    Drupal va très bientôt être équipé d'un nouveau thème d'administration par défaut pour son Back-Office. Le précédent fut conçu il y a 10 ans, et aura bien vécu, mais il n'est tout simplement plus adapté aux usages modernes des contributeurs, en termes d'ergonomie, de design et d'accessibilité.

    Ce qui peut paraître comme un point de détail est une avancée majeure qui va permettre de rendre Drupal plus accessible par défaut à de nouveaux utilisateurs, le rapprochant des standards en termes de Back-Office, comme celui de WordPress par exemple.

     

    • Composer et Drupal

    Composer devient un outil toujours plus central dans la composition de l'ensemble des sites, frameworks et/ou CMS modernes en PHP. C'est en toute logique que la communauté Drupal a continué son travail pour améliorer l'utilisation combinée de Drupal et de Composer.

    Il est désormais possible d'installer et de mettre à jour Drupal en une seule étape, comme le montre la saisie d'écran ci-dessous :

    Composer drupal 8-8

     

     

    • Drupal découplé

    Drupal était déjà l'une des meilleures solutions Open Source où le Backend et le Frontend peuvent être séparés (souvent appelées "headless"). Mais la communauté a encore amélioré cela avec :

          > Une documentation auto-générée via Open API.

          > L'ajout de JSON:API Explorer.

          > Et l'amélioration des performances de JSON:API.

     

    JSON:API Explorer est particulièrement intéressant, rendant JSON API beaucoup plus facile à comprendre et utiliser. Cette fonctionnalité permet de composer une requête JSON:API avec l'aide d'une UI (Interface Utilisateur). 

    Nous avons d'ailleurs récemment développé et mis à disposition un outil similaire pour le site de notre client Paris Musées Collections avec la norme/technologie GraphQL.

    JSON API Explorer

     

    Le passage en Drupal 9

    La sortie officielle de Drupal 9 se rapproche : il ne reste ainsi plus que 8 mois avant de découvrir la prochaine version majeure de Drupal.

    Le passage de Drupal 7 à Drupal 8 fut assez douloureux pour l'ensemble de la communauté. L'ensemble des modules ont dû être réécrits, et certains des modules contribués les plus importants ont mis beaucoup de temps à être prêts en version 8. Drupal Commerce fut ainsi entièrement réécrit et a mis 2 ans avant de revenir à un état fonctionnel et technique comparable à celui qui était le sien en Drupal 7.

    Des leçons ont été tirées de tout cela afin que la prochaine montée de version majeure se passe beaucoup plus simplement.

    Tout d'abord, il fut pris en exemple le modèle de Symfony, où la version majeure suivante (Drupal 9) est égale à la dernière version mineure de la version majeure précédente (Drupal 8.9), moins le code déprécié.

    Et afin d'aider l'ensemble de la communauté à se préparer au passage à Drupal 9. Il existe d'ailleurs dès aujourd'hui, un module dédié pour indiquer si votre site est prêt. Il s'agit de Upgrade Status (à installer via Composer pour pouvoir gérer les dépendances).

    A noté qu'à 8 mois de la sortie de Drupal 9, 16% des 200 modules les plus populaires sont déjà prêts. Une bonne chose étant donné qu'à la sortie de Drupal 8, aucun module n'était prêt en même temps que le core.

    Changement de version majeure de Drupal

     

    Le futur de Drupal

    Mais une fois Drupal 9 sorti, il se passe quoi ?

    Et bien, nous (la communauté Drupal) allons continuer avec l'approche qui a fait le succès de Drupal. A savoir discuter collectivement pour identifier de nouvelles initiatives et travailler ensemble afin de les réaliser.

    Dries propose ainsi déjà 4 nouvelles initiatives pour le futur de Drupal sur le long terme :

    ⦁    Réduire les coûts et efforts pour la gestion d'un site en Drupal.

    ⦁    Prioriser l'expérience des nouveaux utilisateurs. Un nouveau thème pour le Front-Office est d'ailleurs en cours de construction grâce au sponsoring de l'entreprise américaine Lullabot).

    ⦁    Drive the open web  / Aider au développement du Web ouvert.

    ⦁    Etre le meilleur moteur de structuration des données.

    A ce sujet, en tant que developpeur back-end, celle dont nous voudrions ici vous parler plus en détail est l'initiative concernant l'orientation en tant que moteur de structuration des données. Qu'est-ce que c'est que ce terme compliqué ?

    D'après Dries, 4 Milliards de nouveaux utilisateurs arriveront sur Internet d'ici à 2022-2025. Et nous passerons de 20 milliards d'appareils connectés à Internet en 2020, à 300 milliards en 2030.

    Cela devrait engendrer beaucoup de changements majeurs. En plus d'une explosion du nombre de données circulant sur Internet, cela devrait également changer la façon dont circulent ces données, et la façon dont Drupal devrait interagir avec ces données.

    Actuellement, la saisie / l'insertion de contenu dans un site n'a pas beaucoup évolué depuis ces dernières années. Le contenu est entré manuellement dans un Back-Office puis rendu en HTML.

    Mais dans un futur proche, le contenu entrera dans Drupal de 12 manières différentes, et en sortira d'autant d'autres manières (vous l'aurez compris, 12 est un nombre aléatoire).

    Cela signifie également que dans le cadre du développement ordinaire d'un site, nous n'allons plus seulement être amenés à utiliser des WebServices externes mais également à produire des WebServices.

    Drupal Post Browser World

     

    Ainsi, Drupal doit évoluer pour ne plus être seulement un simple répertoire de contenu, mais avant tout un outil permettant de structurer et organiser ce contenu.

     

    Conclusion

    Les DrupalCon sont toujours l'occasion de prendre le pouls de la communauté, de saisir ses doutes et ses aspirations. De notre point de vue, le DrupalCon Amsterdam marque clairement l'entrée de notre CMS préféré dans un nouveau cycle prometteur de développement et de prouesses techniques, pour que cet outil Open Source continue a être le leader dans le monde sans pitié des CMS Open Source. En tant que développeurs Drupal, ces événements sont une source de motivation, d'inspiration et de formation. C'est une fierté d'appartenir à une communauté aussi brillante, active et inclusive.

    On pouvait croire Drupal usé, vieillissant et obsolète... Au contraire, le virage amorcé avec Drupal 8 et maintenant Drupal 9 le replace au centre d'Internet, et nous prenons le pari que si 1 site sur 40 tourne sous Drupal aujourd'hui, ce sera 1 sur 20 dans quelques années, grâce aux efforts de notre communauté.

     

    Post-Scriptum (un peu de tourisme / culture quand même)

    Dans les rues d'Amsterdam, Il fut impossible de tourner la tête sans voir un vélo. Mais nous n'avons pourtant aperçu AUCUNE boutique en vendant. D'où viennent-ils alors ? Comment se sont ils reproduits ? A qui profitent-ils ? Quel est leur réseau ?

    Use PhpSpreadsheet to read XLSX file in Drupal

    jcisio
    01/10/2019
    PhpSpreadsheet cannot open stream wrapper which is widely used in Drupal.

    We have been using PhpSpreadsheet since several years (when it was still named PhpExcel) with Drupal to read XLSX file. The chance is that, we never use it with a stream wrapper, which is particularly widely used in Drupal. Turn out that it does not work with stream wrapper because it uses ZipArchive to uncompress XLSX file and ZipArchive::open() does not support stream wrapper.

    While I think it is reasonnable that ZipArchive does not support stream wrapper because of some limit in the ZIP format and it would be nice that PhpSpreadsheet support it, I just need a way to work around this (then still unknown) problem. Get the real path:

    $filepath = \Drupal::service('file_system')->realpath($uri);
    $speadsheet = IOFactory::load($filepath);

    That's it. I omitted all debugging details by the way.

    PS: the server should have zip extension installed. ZipArchive is used by core, but only in the web installer and thus there is no mention about this extension in the requirement.

    Retour sur le DrupalCamp Paris 2019

    Nono
    21/02/2019
    Les 15/16/17 février 2019 s’est déroulé le Drupal Camp Paris et l’ équipe AOWS était bien sur de la partie.
    Photo de la Tour Eiffel au coucher du soleil

    Les 15/16/17 février 2019 s’est déroulé le Drupal Camp Paris et l’ équipe AOWS était bien sur de la partie.

    Bien que certains dans l'équipe aient arrêté de compter le nombre de DrupalCamps auxquels ils ont participé, c'était pour moi le 1er (après une petite Drupal Europe à Darmstadt).

    Un DrupalCamp, c’est l’occasion de voir où en est l’état de l’art dans la communauté, et j’ai pu assister à 5 présentations business (dont deux des nôtres),

    Les projets présentés représentent assez bien le coeur de cible de Drupal, à savoir :

    • des projets ambitieux,
    • avec des processus métiers complexes, nécessitant des adaptations custom.
    • souvent multisites, et/ou multilingues.

    Et en la matière, nous n'avons pas à rougir des dernières réalisations que nous avons pu sortir .

    Et c’est bien sûr l’occasion de pouvoir assister à des conférences s’adressant aux développeurs, et d’apprendre énormément. Pour les curieux qui seraient intéressés par un bref résumé des conférences, un framapad de prises de notes collaboratives existe : https://paris2019.drupal.fr/programme/prise-de-notes-collaboratives

    Je recommande d’ailleurs la lecture du compte rendu de deux présentations pour ceux qui sont comme moi en train de progresser dans Drupal :

    • Audit de sécurité d'un site Drupal
    • Drupal 8 - Best practices

    Mais s’il ne devait en rester qu’une, LA présentation que je retiendrai c’est celle de Floris Moriceau

    https://paris2019.drupal.fr/programme/sessions/economiser-du-temps-dintegration-dans-vos-projets-drupal

    Une histoire tragique d’intégration d’un site drupal qui tourne mal, inspiré de faits réels.

    • Des maquettes construites sous photoshop et pas du tout conçues pour être responsives (colonnage plus qu'hasardeux).
    • Maquettes qui seront ensuite validées par le client, sans que l’équipe technique n'ait son mot à dire.
    • Et en plus qui seront validées, alors que le périmètre fonctionnel (ce qui sera développé) sera différent (X features en moins).
    • L'UX designeur n'a aucune connaissance des contraintes technique du CMS. Parmi les nombreuses conséquences que cela va engendrer, il y a notamment la prise en compte du principe des "régions" d'un thème, et suivant l'affichage mobile ou desktop, d'essayer d'afficher les informations aux même endroits (un block en sidebar, qui se retrouverait dans le header par exemple).
    • En plus d'être affichées dans des endroits différents, les informations en mobile sont différentes de celles en desktop, sans raison particulière.
    • Et les maquettes pour mobiles arriveront quand on est déjà en train de faire l'intégration. Bref le site est "mobile-last".
    • Des créa de pages de contenu avec un lorem ipsum qui ne dépasse jamais.
    • Les fonts, sur psd chargées en 6 variantes, en vrai c'est pas terrible.
    • Un thème de base  bien connu est choisi sans que le themeur ait son mot à dire (par exemple le tristement célèbre thème boostrap drupal). Thème de base qui sera très difficile à surcharger et rallongera considérablement le temps d'intégration, plutôt que de partir ex-nihilo.
    • Les maquettes en psd sont ensuite recréées directement en page html/css. Et c'est aux devs à faire rentrer ensuite le "vrai" site dans l'intégration. D'après Floris, c'est à minima rallonger le temps d'intégration par 1.5. D'après moi, et pour l'avoir vécu, c'est plutôt multiplié par 3.
    • Le multilingue => Pas de maquettes en plusieurs langues. Alors que certaines polices d’écriture n'ont pas des caractères spéciaux, que certaines langues sont plus verbeuses et peuvent casser la navigation. Et que certaines langues se lisent de droite à gauche. Vous vous rendrez compte de tout ceci pendant la recette évidemment.
    • En pleine recette avant livraison, un audit SEO met en évidence une hiérarchie de titrage calamiteuse (conditionnelle suivant les pages, et incohérente en général). Mais le site est déjà developpé et intégré, et la charge prévue a depuis longtemps été dépassée.
    • Afin de répondre aux diverses contraintes évoqués plus haut, vous avez (ab)user de hooks, de preprocess, de scripts JS custom, etc. C'est un peu comme faire de la chirurgie (pas très) esthétique et de découper une personne pour la faire rentrer dans une taille donnée d'habits.
    • La conséquence directe de ce découpage bizarroïde, c'est que le site est devenu lent.

    J’abonde en tout cas dans le sens de la conclusion :

    "Il faut qu’il y ai un échange permanent entre le designer et le themer Drupal AVANT la validation des maquettes par le client. Cela n'empêchera en rien à ce que les maquettes vendent du rêve, de l'émotion, de racontez une user story dynamique et authentique , etc."

    Et ca tombe bien, cette année nous allons ouvrir le recrutement pour un thémeur et un UX designer, afin d’internaliser ces compétences et d’avoir une meilleure synergie avec les « devs ».

    OpenStack Summit

    drico
    09/05/2018
    Nous serons présent à l'Openstack Summit 2018 à Vancouver !
    openstack summit

    Comme chaque année nous serons présent pour la grande conférence OpenStack. Cette année pas mal de nouveautés à venir, notamment sur les technologies de containers avec notamment plusieurs sessions autour de Kata container le nouveau venu dans le monde des containers sous openstack.

    Egalement au menu :

    • des sessions ceph qui ne manqueront pas de nous donner des idées pour améliorer notre cluster de stockage
    • de la mise en place autour de kubernetes et la gestion des containers docker dans Openstack
    • la haute disponibilité des volumes Cinder
    • et bien sur les goodies de la market place

    Cette année la conférence est conjointe avec un sommet autour du CI/CD ce qui également nous concerne en premier lieu afin d'améliorer nos méthodes du développeur à la mise en production.

    Si vous y êtes aussi n'hésitez pas à nous faire signe, nous adorons échanger sur ces sujets !

    Comment éviter des field_collection vides

    jcisio
    12/02/2015
    Quand on utilise field_collection, dans certain cas, le dernier item d'un champ est vide (une entité field_collection est créée sans aucune donnée utile). Pour contourner ce problème, le module fournit un hook hook_field_collection_is_empty_alter() pour décider quand est-ce un item est vide.

    Quand on utilise field_collection, dans certain cas, le dernier item d'un champ est vide (une entité field_collection est créée sans aucune donnée utile). Pour contourner ce problème, le module fournit un hook hook_field_collection_is_empty_alter() pour décider quand est-ce un item est vide.

    Exemple :

     

    /**
     * Implements hook_field_collection_is_empty_alter().
     */

    function magnard_fiche_livre_field_collection_is_empty_alter(&$is_empty, FieldCollectionItemEntity $item) { if ($item->field_name == 'field_produit_auteurs' && empty($item->field_produit_auteur[LANGUAGE_NONE])) { $is_empty = TRUE; } }

     

     

    Ce morceau de code évite de la création d'une field_collection field_produit_auteurs si elle n'a pas son champ field_produit_auteur (sans "s") rempli.

    Gérer proprement vos modules

    jcisio
    29/09/2013
    Dans cet article, je présente une approche pour ranger les fonctions dans votre module en utilisant la programmation orientée objet (OOP). Cela n'a par contre rien à voir avec Drupal 8.

    Dans cet article, je présente une approche pour ranger les fonctions dans votre module en utilisant la programmation orientée objet (OOP). Cela n'a par contre rien à voir avec Drupal 8.

    Traditionnellement, dans un module, toutes les fonctions sont préfixées par le nom du module et présente dans le fichier ton_module.module. Ça fait un gros fichier ! Même si Dries a dit qu'il ne voyait pas de problème avec un fichier .module de 100 Ko, aujourd'hui on a la tendance de faire des petits fichiers ton_module.*.inc, chacun a une responsabilité unique. Pour utiliser une fonction dans ces fichier :

    • soit on met une require_once au début du fichier .module ;
    • soit on chaque fois on a besoin d'une fonction, on commence par module_load_include() ;
    • soit on charge le fichier automatiquement (le cas avec hook_menu(), hook_theme() etc.).

    Si vous travaillez avec Drupal depuis un peu de temps, vous devriez connaître tout cela. Mais si on veut aller plus loin, on peut mettre les fonctions dans des classes sous forme des méthodes statiques. Les avantages sont :

    • autoload de toutes les classes ;
    • et l'utilisation propre de l'espace de nom.

    Pour l'autoload, vous pouvez mettre classiquement les fichiers dans le .info dans les lignes files[] = ..., ou bien vous écrivez votre propre class loader si vous êtes trop paresseux pour modifier les fichiers .info, sinon vous pouvez en récupérer un avec Google.

    Pour l'espace de nom, ce n'est pas forcément la vraie nouvelle fonctionalité du PHP 5.3 (car il arrive que vous utilisez encore la version 5.2), mais le nom de classe. Vous n'avez pas besoin de préfixer les méthodes dans vos classes. Votre intélligent IDE (vim l'est aussi) pourra avoir des suggestions plus pertinentes. Exemple : vous travaillez sur un projet "vous", avec 20 modules "vous_module1", "vous_module2"..., dans chaque module vous avez des fonctions vous_module1_fonction1, vous_module1_fonction2... et vous tapez "vous" votre IDE va suggérer 10 fonctions qui sont tous dans le premier module vous_module1. Pas très pertinent. Avec les classes séparées, votre IDE présente d'abord des classes, puis les méthodes quand vous complétez le nom de classe. Plus pratique !

    Les méthodes enveloppées dans des classes ne pollue pas le scope global, elles aident aussi pour le refactoring ou le protypage ou le test. Mais l'article est trop long, donc j'arrête. Quand même, avant, pour l'info, ce paradigme est utilisé récemment dans Drupal 7 avec la classe FieldInfo (par yched et al.) et c'est très bien. Il n'y a alors pas de raison pour ne pas l'utiliser.

    PS : un article sans code, mais allo quoi.

    ton_module.inc

    function ton_module_faire_1() {} function ton_module_faire_2() {}

    sera :

    TonModule.php

    class TonModule { public static function faire_1() {} public static function faire_2() {} }