Blog

Nouveau logo Scald

piotre
11/09/2014
Un nouveau logo scald pour de nouvelles aventures, sous D8 entre autres.
nouveau logo scald

Un nouveau logo scald pour de nouvelles aventures, sous D8 entre autres.

Merci à Alex A., Aurélia Z !

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() {} }

DrupalCamp : Paris 2013

DeFr
14/06/2013
Nous avons l'habitude de sponsoriser de nombreux événements Drupal (quelques exemples), mais lorsqu'ils se déroulent à Paris, nous nous devons de faire les choses en grand. Par conséquent, Open Web Solutions a décidé de s'investir sérieusement dans le Drupal Camp Paris, édition 2013.
logo drupal camp Paris

Nous avons l'habitude de sponsoriser de nombreux événements Drupal (quelques exemples), mais lorsqu'ils se déroulent à Paris, nous nous devons de faire les choses en grand. Par conséquent, Open Web Solutions a décidé de s'investir sérieusement dans le Drupal Camp Paris, édition 2013. Très concrètement, vous pourrez

  • Venir nous rencontrer sur notre stand tout au long des 3 jours de la conférence
  • Assister à l'une de nos conférences ou au sprint Scald
    • Le vendredi, de 17h à 17h45, Pierre T vous présentera quelques outils indispensables pour gérer votre projet sous Drupal
    • Le samedi, de 15h à 15h45, Sylvain vous expliquera pourquoi vous voulez utiliser Scald sur l'ensemble de vos projets pour gérer vos media, même si vous ne le savez pas encore. Tous les détails sur le site du DrupalCamp
    • Le samedi, de 16h20 à 17h05, Didier vous parlera de la mise en place de tests fonctionnels automatisés sur vos projets, via les technologies Behat et Mink. Pour plus de détails, c'est par là.
    • Le dimanche, de 10h à 12h, Pierre C vous montrera par la pratique comment construire un site media en 45 minutes. Les lecteurs les plus attentifs n'auront pas manqués de noter les 75 minutes d'écart entre la durée de la construction et la durée de la session, le but étant de multiplier les interactions avec l'audience pour aboutir à un résultat unique.
    • Le dimanche, à partir de 10h, Franck (c'est moi-même…) animera un sprint sur le module Scald
  • Repartir avec l'une des nos nombreuses surprises

A très vite au DrupalCamp !