La semaine dernière un de mes clients m'a commandé une modification sur son site sous Drupal pour lequel il avait avec un "très léger" souci de maintenance... Ce site étant réalisé par une vraie société maîtrisant les "best-practice Drupal" (Views et tout le tremblement), j'ai pensé m'en sortir vitesse grand V... Et pourtant, six heures plus tard j'y suis encore. Tellement abasourdi que j'ai besoin de l'écrire.
Navigation simplissime
Le site en question n'a rien de sorcier. Juste une base d'article tout ce qu'il y a de plus standard, et comme seul "exotisme", un menu principal piloté par une taxonomie arborescente à deux niveaux (rubrique/sous-rubrique). Le principe de navigation est assez simple, un menu principal reflète la taxonomie (menu déroulant donc):
- On clique sur la rubrique, cela donne accès une mini-page d'accueil avec trois articles en avant.
- On clique sur la sous-rubrique, et là on arrive sur la liste des articles comportant le terme de taxonomie correspondant.
Pour en venir au petit pépin de mon client, le site qu'on lui a livré marche parfaitement à un détail près, impossible d'ajouter une nouvelle rubrique/sous-rubrique. Pour ajouter les termes dans le vocabulaire adéquat, pas de soucis, mais pas de menu non plus. Il a bien essayé de régler le problème, tenté d'ajouter une page à la vue correspondante, tenté de faire le menu à la main, rien à faire. C'est là qu'il m'a refilé le bébé...
La main de la confeature
Souvent quand j'évoque ma manière de travailler avec Drupal, on me rétorque "Ouhlà, tu fais du code custom, c'est pas standard, faut utiliser des modules, sinon comment-ki-font-les-suivants-pour-maintenir". J'étais donc positivement curieux de voir comment un site fait par une société "state of art of drupal" était construit. Et je n'ai pas été déçu du voyage même si je ne sais pas encore bien comment je vais faire celui de retour...
Pour commencer, je me suis pris un usage extensif du module feature. Pour être honnête, j'ai une opinion assez mitigée sur ce générateur de module. Mais utilisé comme cela, je lui confère le titre d'hallucinante usine à gaz au fonctionnement proche de l'enregistreur de macro d'une suite bureautique. En fait features me rappelle le gag du développeur fou à qui on demande de corriger une fonction sensée renvoyer la somme de ses deux arguments. La fonction semble fonctionner, mais lorsqu'on lui donne à manger 1 et 1, elle renvoie 3. Le développeur fou ne tarde pas à trouver la solution en retirant fièrement 1 au résultat final...
Fatures c'est un peu cela. Drupal est in-fichu de proprement gérer un déploiement ? Et bien qu'à cela ne tienne, nous allons créer un générateur de module dans lequel on va injecter du code PHP représentant toute la configuration spécifique pour un site donné (les types de contenu, les champs cck, les vues..). Et comme en standard feature ne connait pas grand chose, on va lui coller features_extra qui va en plus permettre d'y coller les blocs, les menus et la taxo. Et comme un site drupal c'est loin de se limiter à s'y peu, pour le reste, on se démerde à coup de strongarm et du code custom... ah ahhhh !! je ne suis donc pas si seul :-)
Au final on hérite d'une chiée de module qui n'en sont pas vraiment car ils ne s'installent/désinstallent pas normalement, mais uniquement à travers l'interface de features. Ce dernier est alors censé mettre magiquement à jour le site sur lequel les dits modules sont déployés et redéployés. Sauf que c'est un peu de la magie à la Garcimore dès qu'il s'agit de choses un peu complexes comme la suppression d'un champ cck, au hasard...
Entendons nous bien, je suis parfaitement prêt à entendre l'intérêt de feature dans son concept même d'API exportable. Mais en l'état, le fait que ce ne soit qu'un module contribution et pas une api du coeur de drupal fait que sur une installation standard, 80% des paramétrages ne sont pas couvert (en gros dés que l'on sorte de CCK et Views). Du coup l'outil est trop contraignant pour un résultat bien modeste. De plus, lorsque le module généré est, comme pour ce projet, hacké jusqu'à la trogne, on perd tout l'intérêt de la manoeuvre car toute mise à jour de la feature est vouée à l'échec. Il s'agit donc plus de l'usage du module et de son périmètre qui pose problème, que sont idée de dépard.
Ils m'en ont mis plein la view...
En conclusion, les "state-of-art-of-drupal", comme moi, font du code (celui nécessaire pour tout ce que feature ne gère pas). Mais ma réelle découverte, c'est qu'ils font surtout du code pour télécommander des modules... Moi pour faire une liste, je fais une requête SQL, un db_query, un template pour formater le résultat de ma callback, et hop, à Créteil... Eux non. Eux ils utilisent Vieeeewzzzzzz, mais pas comme le pekin lambda, eux ils font du views, dans du code. Des milliers, je dis bien des milliers de ligne de code (4500 pour être exact...) pour paramétrer la génération automatique de vues, de pages associées à ces vues, de feeds, etc, etc, etc... Tout cela innocemment collé dans un hook_default_view_views...
Alors cela "fonctionne" finalement ? En bien pour commencer, nous avons un module pour faire la synchronisation entre le vocabulaire des rubriques/sous-rubriques : taxonomy_menu. Bon, pourquoi pas.
Pour gérer la page "front" et ses 3 articles mis en avant, on ajoute le module nodequeue et l'on fabrique une queue par rubrique. Là, la question est "comment fait-on pour associer une queue et une rubrique". En effet, elle est bonne la question... Car en fait on peut pas. Alors les astucieux ont écrit dans un module custom (encore du code !!) une fonction qui permet d'associer les queues au terme de vocabulaire en passant... par un tableau PHP en dur... Là pour le coup mon pov' client, il ne risquait pas de pouvoir ajouter sa rubrique de si tôt.
Ensuite, parmi les 4500 lignes de génération de vues, s'en trouve un millier dédié à fabriquer les vues/pages/feeds associés avec chaque rubrique en mettant ainsi la vue en relation avec le nodequeue qui va bien, grâce à la fonction PHP magique.
Après encore une grosse poignée de centaines lignes pour générer cette fois les vues des sous-rubriques et on est presque arrivé... Là on se dit qu'on aurait pu en profiter pour associer un menu à chaque page de vue ! Mais non, navigation_menu qui est trop super sympa !
En comme la vie serait triste si l'on n'utilisait pas context, on a rajouté quelques centaines de lignes de code supplémentaire pour générer les contextes associés à chaque rubrique et sous-rubriques...
Résultat des courses, views, nodequeue et context dans une interface graphique à faire fondre les plombs à FireFox (imaginez, une vue, 50 sous-rubriques, 100 onglets tout en ajax ;-). Interface qu'il ne faut absolument pas utiliser puisque tout est généré. Du coup l'intérêt de Views est incertain, mon client ne peux pas les modifiers et le développeur, lui s'empêtre dedans..
Ajouter une rubrique, mode d'emploi...
A ce stade, le client il est sous terre... Car finalement le manuel du "comment ajouter une nouvelle rubrique/sous-rubrique" ressemble à cela :
- Aller dans la taxonomie pour créer la rubrique et la première sous-rubrique. Taxonomy menu n'a pas fonctionné, le menu n'est pas créé, c'est normal car la page n'existe pas encore... Le lien en lui même (taxonomy/term/xxx) ne fonctionne pas non plus vu que c'est ce type de chemin qui est utilisé par les pages de views et que du coup il y a conflit sur le routeur (c'est certain, il vaut mieux une vue plutôt que thémé simplement la page de taxonomie).
- Créer un nodequeue...
- Aller dans le code pour le modifier et ainsi associer ce nodequeue à l'intitulé de la taxonomie (pourquoi pas directement le tid ?)
- Aller dans views, sur la vue "frontpage", cliquer sur modifier puis la supprimer. Si si, car sinon, Views ne réimporte pas proprement les vues par défaut générées plus haut. Au passage, pleurez un peu car évidemment les vues ont été un peu customisées juste ce qu'il faut pour passer 1/2 heure à les régler à nouveau (opération à refaire à chaque ajout de rubrique, youpi...)
- Même motif et même punition pour la vue "sous-rubrique"... Mais heureusement j'ai découvert que je pouvais revenir (aka supprimer...) à partir de la liste des vues, donc firefox est sauvé. Ne pas s'étonner qu'à chaque click sur un lien de views ça mette 10 ans à réagir, car l'implémentation du hook responsable de la génération des vues par défaut est appelé à chaque fois...
- Revenir sur la taxonomie cliquer sur modifier puis directement sauver, et cette fois le menu devrait être créé..
Pour s'en sortir...
Maintenant je ne sais pas trop ce que je vais faire. Je me doute bien que mon client ne sera pas très ravi avec la procédure que je viens d'énoncer. La première étape va donc consister à dégager feature/strongarm pour y voir plus clair. Puis j'imagine que je vais mettre en œuvre un truc un peu plus simple.
- Un type de contenu "Rubrique" avec un titre, un corps et une liste de trois nœuds (nodereference). Le principe sera pour le client de créer un nouveau contenu de type "Rubrique" lorsqu'il en aura une à rajouter. J'associe automatiquement ce contenu au menu de premier niveau et avec un hook_nodeapi je fabrique synchronise le premier niveau de taxo rubrique. En gros 10 lignes de code. Du coup la rubrique étant un nœud associé à mon premier niveau de menu, je gère la "frontpage" par un simple node template. Emballé.
- Pour les sous-rubriques, je laisse le client ajouter ses termes de taxo et je laisse navigation_menu les associer proprement. Du coup la liste des articles est simplement un template sur la liste standard de drupal des articles possedant un terme donné.
Donc en somme, si l'idée fonctionne, une usine à gaz avec 4500 lignes de code Views d'un côté, et un petit module custom disons de 100 lignes, pas de vues, et une pure exploitation des fonctionnalités de base de drupal. Sans aucun doute moins sexy ;-)
Conclusion
Il ne faut pas croire que je sois de mauvais esprit ici. j'ai même un certain respect pour la personne qui a servi de référent technique sur ce projet. Mais cette aventure a été instructive à plus d'un titre. Tout d'abord cela me décomplexe lorsqu'on me dit "Bouh, tu fais du code custom, c'est moins facile à maintenir que des modules". C'est sans aucun doute vrai lorsque le besoin est assez simple pour que les modules utilisés se suffisent à eux-même. Mais pousser la logique modulaire au point de télécommander des modules avec des milliers de lignes de code, c'est aberrant. Aberrant car je suis persuadé que mon équivalent "code simple" est cent fois plus lisible (en tout cas il est 100 fois plus documenté...). Ensuite ces modules ont été pensés pour être utilisés à travers des interfaces graphiques. C'est d'ailleurs souvent dommage car j'aurais préféré, même pour views, que l'API précède l'interface pour que tout le monde soit content. Toujours est il que du coup leur paramétrage ressemble plus à un remplissage de formulaire qu'à l'utilisation d'une API propre. Enfin, purée c'est d'une lenteur tout cela. A chaque click on a l'impression de manipuler un 38 tonnes avec des baquettes de tambour... et chaque "frontpage" de rubrique génère, pour un utilisateur authentifié, pas moins de 786 requêtes SQL !!!!!!!!!!
En conclusion, ce que j'en retire c'est que context est un module qui mérite que l'on s'y penche mais je lui reproche sa dépendance à ctools absolument inutile et proprement rédhibitoire. Feature est une plaisanterie. Drupal a un problème de déploiement indéniable et même grave à l'heure d'un usage professionnel de l'outil. Feature n'est donc qu'un emplâtre sur une jambe de bois. C'est lourd, peu stable, et surtout ne couvre pas toutes les fonctionnalités obligeant à recourir à du code custom. Autant utiliser Backup & Migrate. Views est un très bon outil pour le cadre d'usage "wordpress" de drupal (non péjoratif, car j'aime beaucoup wordpress), permettant à un utilisateur peu ou moyennement expérimenté de construire son site rapidement. Dans le cadre d'un usage professionnel par des développeurs professionnels, l'utilisation de cet outil comme API ne m'a clairement pas convaincu. C'est bordélique au possible et je crains le pire lors des changements de version (en gros views3 implique tout à la poubelle, comme ce fût le cas pour Views1).
Juste comme ça… tu pourrai m'envoyer le nom de l'entreprise par mail… histoire de voir si je connais pas quelqu'un pour comprendre ce qui a put "merder" à ce point, ou qu'au moins je sache à quoi m'attendre si je collabore avec eux…
Ah non, désolé, je ne fais pas ce genre de chose :)
Après ce qui a pu merder pas fois, je pense que c'est la croyance dans ce merveilleux monde du Oeubeuh, que les spécifications techniques et la conceptions sont des choses vieilles poussiéreuses et inutiles ;-)
Autant je suis entièrement d'accord sur ton article sur le fait que tous ces modules d'abstractions (views, context,...) ne servent strictement qu'à retarder le moment où l'on va coder à la custom (et par là même, faire croire qu'on peut faire un site Internet PHP sans coder, au travers de wizards et autres joyeusetés), autant je ne pense pas que les specs techniques et la conception sont la solution à ce problème.
Ce qui manque surtout, ce sont de bons développeurs, pragmatiques, et des clients qui comprennent le sujet pour lesquels ils payent.
La simplicité de coder custom en deux temps trois mouvements est justement la grande force de Drupal, alors, autant en profiter !
Désolé de te contredire mais l'un ne va pas sans l'autre, et là c'est l'ancien chef de projet qui parle. Sans conception claire, qu'il faut plus prendre comme des choix d'implémentation et d'architecture à priori (cad avant que le codage ne commence), les meilleurs développeur produisent un caca d'ampleur inversement proportionnel au temps qui les séparent de la livraison. Pour le projet qui a motivé ce billet, je suis persuadé que ce sont de bon développeurs (d'ailleurs j'en suis non seulement persuadé, mais je le sais pour les avoir vu travailler).En fait quant tu reprends un projet comme cela tu vois bien les étapes, d'abord tout est cool, on se dit "allez Features c'est trop top, les views dans le code c'est trop top, context c'est trop top, voilà, notre architecture est décrite, vite, vite, on code"... Et au 2/3 du projet les ennuis commencent "Ah merde, finalement Features c'est pas si top, il gère pas ça et ça.. trop tard, faut avancer, on va faire une glutte..", et puis "Oh zut, on avait pas pensé qu'on avait des sections dynamiques à ce point là, Features et Context sont à la ramasse, bon, ok, on va créer les vues à grand coups de requêtes et de boucles". Et 3 jours avant la livraison, "Oh crotte, on a oublié tel ou tel détail, bon,vite, on a plus le temps de coder, on va surcharger en base les belles vues codées avec les deux trois détails qui manque"... C'est comme cela qu'un principe à l'origine "bon" disant "on fait nos vues, on les exportes dans features, et on les déploie en prod" se fini avec une seule vue sur 20 dans features, le reste créé à coup de boucles dans un module custom à part et le tout surchargé en base de données...
Tout cela avec une gestion de projet solide et une phase de conception consciencieuse aurait pu être évité. Avec une phase de conception, ils auraient pu déminer leur choix en les envisageant jusqu'au bout.
Donc oui de bons développeurs sont un must, oui Drupal permet de coder rapidement, mais non, désolé, sans conception, je ne connais pas un seul projet qui tienne la route, du moins en mode "forfait". En régie "agile", c'est une autre histoire ;-)
Justement, personne n'a jamais le temps de "concevoir" jusqu'au bout, simplement parce que tout concevoir revient à la même chose que faire le projet. Pourquoi faire un proof of concept à côté, et tout recommencer après parce qu'on a décidé que cela marche. Et comment décider que cela marche sans avoir valider dans des cas concrets notre solution (= en production).
Bref, à mon sens, mieux vaux être pragmatique (quitte à supprimer en cours de route une dépendance devenant trop lourde), ne pas présumer du futur, et faire les choses le plus simplement possible (= pas trop de modules de haut niveau dans Drupal) - oui, je parle agile là.
PS : C'est le développeur qui parle (et qui considère - ne le prends pas mal - que les chefs de projet sont inutiles ;-)
[Hors propos] Je suis médusé : comment ton Drupal a-t-il retrouvé mon avatar ?
tu dois avoir un compte gravatar... Ce truc est une calamité, j'ai une tete de con sur tous les blogs où je poste maintenant, il faut que je reprenne ma vie en main.
Ehéh ! Donc, en se basant sur le nom (posté en non authentifié), on peut utiliser l'avatar de n'importe qui ? Bon, mon prochain message sera de Barack Obama (espérons qu'il ait un compte Gravatar) ;-)
"Je suis médusé : comment ton Drupal a-t-il retrouvé mon avatar ?"
Parce que ce site a été conçu avant d'être développé, par un développeur ET chef de projet ;pppp
@lastnico
Pour être un développeur sur des projets qui vont de moyenne à grosse envergure (en gros de 10 jours de dev à 1 an de dev), laisse moi te dire que si, les chefs de projet sont indispensable. Pour des milliers de raisons, la première étant qu'un développeur ne devrait jamais être amené à négocier en frontal avec le client (un développeur se surestime toujours, le client en demande toujours plus, et la double responsabilité te pousse immanquablement à faire de la merde, c.f. Single Responsibiliy Principle).
Ne serait-ce que pour ça, un chef de projet, c'est nécessaire. Et je détaille pas, mais il y a encore 999 autres raisons :)
"C'est le développeur qui parle (et qui considère - ne le prends pas mal -
que les chefs de projet sont inutiles ;-)"
je ne le prends pas mal, c'est juste une question de taille de projet. Et de plus si tu n'as pas de respect pour cette profession, c'est que tu n'as jamais du avoir de chef de projet compétent, c'est à dire qui soit à la fois chef de projet et expert technique dans la technologie mise en oeuvre dans le dit projet. D'ailleurs ce n'est pas un hasard si le seul projet où je me soit planté en beauté est celui dont je ne maîtrisais pas la techno (.net ;-).
pour information, mes métriques sont assez simple et prouvent que je suis dev avant d'être cdp. D'abord j'évalue le temps de développement, et ensuite je prends 30% de ce temps, c'est le temps de conception. Et 20% de ce temps, c'est le temps de test/recette. Mais là je te parle de projets qui dépasse les 70/100 jours/homme. Pour des petits projets, les ratios ne sont pas les mêmes.
je crois que ça se base sur l'email en fait (chuis pô sur)
"Bon, mon prochain message sera de Barack Obama"
Je vois que lastnico n'a pas bien pris conscience du travail de pigménico ;-) LEN2 et usurpation d'identité ;-)
"Ce truc est une calamité, j'ai une tete de con sur tous les blogs où je
poste maintenant, il faut que je reprenne ma vie en main."
Je ne suis pas si fan du principe que cela mais ça met un peu de couleurs dans les commentaires :)
Ahah ahah ;-)
Et bien ma logique "Aucune conception" me permet, sans rien rédiger au préalable, d'installer immédiatement le plugin Gravatar sur mon site et de bénéficier de cet avantage en quelques minutes ;-) ... Tout en le désinstallant dans 3 mois, car mes utilisateurs considéreront cela inutile, ou que ce module fera ramer le site comme pas permis ;-)
Pour les petits projets, la ratios devraient être doublés, moins le client veut payer, plus il est demandeur (totalement logique, le radin essaye de grapiller tout ce qu'il peut).
" la première étant qu'un développeur ne devrait jamais être amené à
négocier en frontal avec le client"
héhé, j'avais fait le coup une fois à un de mes gars qui trouvais lui aussi que c'était pas très utile un CdP, je l'ai mis en relation direct avec le client dans le pur mode "vie ma vie" pendant une semaine. Passé ce temps il m'a supplié de reprendre mon job ;p
Si tu le désinstalle 3 mois après, au prix de te retrouver avec plein de grabuge dans ta base de donnée, sur les fichiers de ton FS, etc... c'est une erreur de conception :)
@pounard
"Pour les petits projets, la ratios devraient être doublés, moins le
client veut payer, plus il est demandeur (totalement logique, le radin
essaye de grapiller tout ce qu'il peut)."
ça se défend :) Moi ce que je vais pas tarder à faire c'est des ratios de facturation suplémentaire en fonction des technologies demandes : IE6 +20%, Views +15%
EDIT: C'est quelque chose que j'ai jamais compris d'ailleurs. Un client
de supermarché achète un jean à 10€, il le jette 3 mois après parce
qu'il est déchiré et ne se plains pas. Un client d'une SSII commande à
un site à 5000€, il est averti qu'à ce prix là, on peut pas lui assurer
Fesse-bouc, et avant même la recette il vient pour dire que c'est une
honte à ce prix là et exiger son Fesse-bouc.
Le pragmatisme en conception, ça existe aussi, ça revient à ne pas faire de sur-engeneering et de coller au besoin :) Ça n'empêche bien sûr pas de prévoir les évolutions et de prévoir une certaine souplesse dans toute cette simplicité.
@yoran
Sans être lié à mes expériences précédentes, il me semble qu'une équipe de dév se doit d'être à plat, les décisions devant être collectives. Enfin, plus que Drupal et ses modules jefaistout-ouiouicestpossible, c'est plus contre le développement cycle en V, les prestations SSII à forfait genre mon site n'évolue plus à la livraison et les hiérarchies récursives de personnes que j'en ai ;-)
En bref, et si vous ne l'aviez pas compris : Extreme Programming Powaaaa!
@pounard
Bien entendu, il est indispensable de conserver un référent unique client, qui centralise les échanges avec lui, mais le considérer par la même "chef de projet" n'est pas spécialement
Ah oui, parmi mes griefs, j'oubliais : j'estime à la pelle le temps nécessaire pour un projet, et je le multiplie par 2 ;o)
Ce qui en fait.... ne marche jamais ;-)
@lastnico
Je suis assez d'accord, ce que tu décris c'est une façon de procéder pour des petites équipes sur des projets en méthode agile (encore un gros mot). Et en effet, les décisions doivent être collectives, ce qui sous entends d'en discuter, ce qui revient à de la conception.
Un référence client unique se doit de ne pas être développeur sur le projet, avoir une double casquette et une double responsabilité, ça marche jamais (ou rarement), dans le cas concret la personne qui fait de la relation client se doit aussi de planifier, tout au moins de mesurer l'avancement et la réalisation pour avoir de la consistence devant le client et détecter les problèmes.
La détection des problèmes, sur une équipe plate, est très dure, il y a toujours une brebie galleuse qui à un moment se retrouve bloquée et "oublie" (plus ou moins volontairement) d'en parler, et sans le couperet d'un chef au dessus, ne le dira à personne. Car pour détecter les problèmes, il faut qu'il y a une personne qui centralise et qui fasse un état d'avancement.
Tout à fait, il n'y a pas que des über développeurs. L'XP permet de pallier les problèmes de développeurs moins sûr d'eux, ou moins courageux pour annoncer les problèmes rencontrés, notamment en faisant réduisant au minimum chaque tâche, et en panachant les équipes de dév (le sacrosaint pair programming)... même si ces pratiques sont beaucoup plus durs à mettre en place, notamment à cause de la planification et de l'estimation des délais (exemple : 1 tâche = 14 jours homme = 1 développeur à plein temps || 2 développeurs sur 7 j) qui donne l'impression, pour un responsable non technique d'une division par 2 de la vélocité du développement.
Solution Alternative : En étant pragmatique, tu ne sais pas quels plugins tu utiliseras à l'avenir, mais tu te doutes que certains seront foireux, donc tu utilises des outils simples pour t'en prémunir : gestionnaire de version des sources (SVN, GIT), dumps et diff de squelette des bases. De cette façon, tu as toute les cartes en main pour ne perdre qu'une heure lors de la désinstallation.
(évidemment, le but n'est pas de tout essayé en production et de se faire hara-kiri, les mauvais modules ne deviennent mauvais que parce que tu les as cru suffisamment bons pour les mettre en production)
Ouaip, mais la découpe des tâches, encore plus quand il s'agit d'intégration et non de développement devient très difficile au delà d'une certaine granularité. Surtout en intégration, on fini toujours par se retrouver avec des intégrateurs qui font le même boulot pour arriver à boucler chacun leur tâche.
Par contre, le pair programming, c'est diablement efficace, et ce n'est pas une pratique qui est forcément lié au cycle de développement choisi, on peut faire du pair programming quel que soit le contexte. Et ça, c'est vrai que ça roxxe à fond, ça avance beaucoup plus vite que deux personnes chacune de leur côté contrairement à ce que beaucoup pourrait croire :)
"L'XP permet de pallier les problèmes de développeurs moins sûr d'eux, ou
moins courageux"
Arf, moi qui croyais que c'était mal de penser "XP, c'est prendre deux mauvais développeurs pour en faire un moyen" (pounard, humour, pas taper ;-)))) Moi le pair programming j'ai jamais pu, ça me met dans un état de rage dangereux pour le coéquipier :)
En plus l'XP, ça m'évoque la secte qui officiait (et officie surement toujours vu comme ça dépotait ;-) aux AGF avec leurs "standing mettings" minutés, leur petite fiches et leurs chronos, et surtout l'aire sérieux et pénétré :) Peut-être est-ce XP dans le monde des javaistes mais j'en ai une vision plutôt mormonesque :)
Ah oui, mais ce n'est plus de l'ordre de la planification, mais c'est un
problème humain, c'est la que le RH est censé intervenir :D Si tu mets
deux fortes têtes ensemble, soit ça canalise les comportements, soit ça
explose!
ça doit être ça oui :) Et puis bon, les séances de dev qui se finissent avec du sang et une touffe de cheveux sur un clavier, ça fait tâche :)
Plus sérieusement, comme je le disais plus haut, je n'ai jamais vu ce genre de pratique opérées dans la joie et la bonne humeur, j'en ai donc une image détestable. Et de toute façon, je suis trop vieux pour cela maintenant :)
Ce genre de problèmes ne sont-ils pas quelque part incident à l'usage abusif de CMS "censé tout faire tout seul" (à condition d'en recoder la moitié).
J'ai souvent rencontré le même genre de problèmes avec des ERP qui au final donnait plus de boulôt que de se coder une solution maison…
J'espère que tu as tord en réalité. Drupal m'a à l'origine séduit pas son ambivalence. C'est une plateforme de développement d'un côté, et un assembleur d'application web de l'autre. Juste pour être plus clair, c'est à la fois un Wordpress, et un Symfony. Et il est possible pour chaque besoin de passer dans l'un ou l'autre des deux modes.
Maintenant ce fût le cas, je ne sais pas si ça le sera. J'ai de plus en plus l'impression que la "communauté" drupal cherche à emener l'outil vers un super-wordpress, au détriement des API et de l'aspect Framework. Pour l'instant ce n'est qu'une impression que je confirmerais ou j'infirmerais en portant mes modules sous Drupal 7.
Mais à l'heure actuelle, si une équipe de développement choisi de s'orienter dans le sens de ce que je viens d'écrire dans ce papier, c'est clairement un positionnement (que j'espère conscient). Et il y a dans Drupal, de par cette ambivalence, moyen de bénéficier des modules pour aller vite, tout en utilisant les API pour taper finement sur un besoin.
" J'ai de plus en plus l'impression que la "communauté" drupal cherche à
emener l'outil vers un super-wordpress, au détriement des API et de
l'aspect Framework. "
Dries explique clairement qu'il veut cibler à la fois les end users type joomla / wordpress (je fais un site en juste en cliquant) et les développeurs (bon, maintenant que les modules installés m'ajoutent de la m**** partout que j'ai n'ai pas demandé, hookons tout ça, retranchons, modifions, hardi moussaillons, preprocessons ! ).
La priorité de Drupal est de conquérir le monde, en étant à a fois user-friendly et ultraflexible. Une équation qui peut mener à une certain schyzophrenie : la module doit tout faire tout seul pour l'utilisateur qui ne sait pas coder; quant au développeur il doit trimer derrière pour tout ajuster afin que cela corresponde à ce qu'il voulait pour de vrai.
Un CMF comme modx à un énorme avantage : il vise clairement des gens qui doivent au moins connaitre sur le bout des doigts le html et le css; et n'impose jamais quoi que ce soit : on paramètre dès le début ce qu'on veut. Le besoin en overrides est très faible, alors qu'il gigantesque avec drupal (on passe son temps à ça en fait, sauf à refuser d'utiliser les modules; mais alors pourquoi prendre Drupal ? est ce vraiment le meilleure framework php existant aujourd'hui ? )
Très intéressent comme billet.
Les rares sites que j'ai fait l'ont étés avec cms-ms.
Personnellement, je préfère Jaws (jaws-project) qui tient plus de framework que du cms.
Avec Drupal, je ne me suis jamais fait à la logique de ce cms. Et ce n'est pas faute d'avoir essayé.
Comme je le dit toujours, il faut évaluer les besoins et estimer les besoins futures.
Drupal pour quelques pages c'est utiliser la bombe H pour tuer une mouche.
Je comprend que l'entreprise ai utilisé l'outil qu'elle maitrise, mais force est de constater ici qu'il aurait été préférable de prendre autre chose.
Là je ne suis pas d'accord, j'utilise même Drupal pour mon intranet familliale car pour moi qui connaît un peu l'outil, c'est beaucoup plus simple à mettre en oeuvre que Wordpress. Là le problème n'est pas que l'outil soit innadapté, mais que l'on pousse une logique qui elle est innadaptée.
768 requêtes sur des homepages? Si tu savais mon pauvre ami, si tu savais...
Par contre tu as eu une mauvaise expérience de features à mon humble avis.
Ici on l'utilise pour industrialiser certaines fonctionalités et c'est aux petits oignons.
Enfin pas moi moi je suis sur du symfony faut pas déconner :q
Oh mais je sais, j'ai eu entre les mains un autre projet Drupal, là aussi conçu par une tip-top webagency, avec une page à 14000 requêtes (non, je ne plaisante pas) et 4000 requêtes en moyenne pour le reste... Pour moi, un site Drupal potable c'est en dessous de 300 requêtes en moyenne par pages minimum.
Pour ce qui est de features, je ne dis pas que cela n'a pas un usage dans le cadre que tu décris : extraire un sous-ensemble de fonctionnalités pour en faire un module. Mais là, ce n'est pas le cas, c'est utilisé pour déployer toute la configuration du site... Et là, ça colle plus du tout. Ceci étant dit, pour features reste pour moi une grosse glutte car les modules générés sorte du cycle de vie classique des modules. Pour que ce soit utilisable, il faudrait que l'on puisse les installer/activer/mettre à jour/désactiver/desinstaller par la gestion standard des modules de Drupal, pas par une verrues qui fait doublon. On est typiquement là dans le cas d'une faiblesse de Drupal que les mecs comblent en créant un système parralèle. J'aurais 100x préféré qu'ils patchent le noyau pour améliorer de manière générale la gestion de modules.
" On est typiquement là dans le cas d'une faiblesse de Drupal que les
mecs comblent en créant un système parralèle. J'aurais 100x préféré
qu'ils patchent le noyau pour améliorer de manière générale la gestion
de modules."
Bah justement, vu qu'ils veulent pas patcher pas le noyau (on croise les doigts pour drupal 8 mais bon ... ), features et ctools ont le mérite d'ouvrir le débat pour montrer ce que ça pourrait donner si on développait dans Drupal une véritable API des exportables.
Features mal utililsé peut être un enfer, mais ne jetons pas le bébé avec l'eau du bain ;-)
Bonjour, intéressant article en effet, un bon exemple de ce qu'il ne faut pas faire!
Ceci dit, pour avoir audité pas mal de code dans une grosse phase de R&D, je peux dire que le principe de features est globalement bon. Je m'explique, features est taillé pour générer l'implémentation de hooks Drupal (exemple, le hook_views_default_views()), afin d'exploiter les fonctionnalités d'import/export déjà existantes de modules contrib.
Quel avantage y-a-il à ça? Le premier c'est le fait de pas faire le .module d'origine à la main. Je dis bien d'origine, car les diverses documentations de features précisent bien qu'une fois une feature créée, on n'est pas obligé de réutiliser le module features ad vitam eternam, ce qui est créé est un vrai module Drupal valide, qui implémente un certain nombre de hooks. Une fois ce module créé, libre au développeur de le transformer, je me permets l'expression, en grosse bouse s'il le désire.
Bref, tout ça pour dire que features est loin d'être le mal, il suffit de l'utiliser avec parcimonie. Dans beaucoup de cas il peut s'avérer très pratique, je dirais que son aspect le plus utile est de loin le fait de pouvoir exporter les types de contenu en utilisant les hooks du module Content.
Views tout le monde le sait, tue des chatons, le code de ce module est probablement le plus moche que j'ai vu des modules Drupal (juste après Taxonomy Menu, qui porte lui aussi le poids de son passé, et buggue énormément dès qu'on sort du use case basique).
PS: Le captcha me pose toujours la même question.
@Nyl & pounard
De mon point de vue, Features est aux modules, ce que l'enregistreur de macro de word est au développement. L'illusion de gagner du temps pour au final, si l'on a un peu de conscience professionnelle, finir par tout se retapper à la main. Comme le disais Nyl plus haut, Features ouvre certainement la voie. Le soucis c'est qu'il va être utilisé un max avant que drupal n'intégre la notion d'exportabilité aux modules (Nyl pense à drupal 8, je suis moins optimiste). Entre temps feature va chercher à faire papa-maman et se substituer à Drupal au point où l'on va avoir des modules "features" et des modules "natif". Je pense que ça va être un sacré souk. Et tout cela parce que les modules sont purement et simplement mal conçus. Leur structure n'a pas évolué depuis drupal 4... ça commence à dater avec un niveau de contrainte proche de 0. Les modules sont en réalité de bêtes includes PHP avec une couche de gestion des hooks. Entre autre lacune, pas de stockage des settings imposé ce qui implique l'apparition du dit features qui sans cela n'aurait pas eu de raison d'être.
PS: oui le captcha pose toujours la même question totalement stupide mais pour l'instant 100% spammer proof :-)
Pour features il y a clairement un décalage entre la pratique et le paradigme affiché.
Ceci dit je pense que le principe est bon : oui il est bon que le code puisse vivre dans un fichier, et pourquoi pas utiliser un module (features) permettant d'exporter d'un coup toute la config plutôt que d'exporter à la mimine tous les exportables de chaque module (ce qui est juste impossible). Le probleme ne se situe pas là (en réponse à ta remarque sur la macro d'excel).
Mais je suis tout à fait d'accord sur l'immense fossé entre l'idéologie de features et ce que permet Drupal aujourd'hui; ce qui implique d'ailleurs dans le code de features ou de context des contorsions assez flippantes.
Tu sembles très pessimiste quant à features, mais je respectes ça, je suis d'accord que ça fait assez peur. Mais il faut bien voir deux aspect distinct:
Dans tous les cas, que l'on utilise features pour ses facilités, ou qu'on fasse exactement le même travail à la main dans un module custom, ça revient exactement au même. Si on connait pas features dans le premier cas, on fait de la daube, si on connait pas l'API de Drupal dans le second, même constat.
@Nyl je suis absolument d'accord, le principe d'origine est bon, mais ce qui pose problème ici n'est pas plus le principe que sa mise en œuvre. Un exemple, sur ce projet j'ai des newsletters à paramétrer, comme fais-je pour coller cela dans Feature ? Je dois développer. Et de même pour tout ce qui n'est pas Views, CCK, Nodequeue, Taxonomy et menu (ah non, menu ça marche pas non plus ;-). Ensuite je pris dans le cadre d'un configurateur, le principe ne me chose pas bien au contraire. Si j'avais eu cela pour mediapart, je n'aurais pas développé un outil qui fasse à peu prés la même chose (mettre la configuration dans du code). Maintenant ce qui me géne avec Features c'est qu'il va plus loin qu'un simple configurateur, il autorise la mise en place de cas particulier, de logique interne qui rend le module indispensable même une fois que son travail de déploiement est achevé. Et c'est peut-être cela qui me géne le plus. Features veut répondre à deux besoins : encapsuler un ensemble de fonctionnalités pour les déployer sur plusieurs sites comme des modules, et permettre le déploiement de configuration sur un site donné. Si features répondait uniquement au second besoin, il génèrerait de vrais modules avec seulement des procédures update dans un .install, et ça m'irait très bien. Mais à vouloir répondre aussi au premier besoin, le module devient un élément qui vient un peu plus allourdir l'édifice drupalien déjà bien épais. A titre d'exemple pour étayer ce second point, les vues intégrées par features ne sont pas stockées en base, ce sont des vues par défaut. Ce qui veut dire qu'on repasse dans le module de la feature à chaque fois que l'on utilise l'UI de views, ralentissant encore un peu plus une manoeuvre déjà bien lambine.
Tout ça pour dire que je ne noie pas le bébé avec l'eau du bain, mais je reste persuadé que qui trop embrasse, mal étreint. Mais cela ne va pas m'empêcher de pousser sa logique sur ce projet histoire de voir si on peut arriver à en faire quelque chose malgré tout.
@pounard je me rend compte que tu résumes bien mieux que moi l'ambivalence de features, j'aurais du te lire avant de répondre à Nyl :) Mais ceci dit cela m'a permis de comprendre ce qui me bloque le plus. Pour moi, l'avantage de coller ce genre de chose dans un module custom en utilisant une couche d'helpers comme Install Profile API, c'est qu'une fois que le drush updatedb est lancé, je n'ai plus à me préocuper du dit module. Il devient inerte jusqu'au la prochain déploiement.
@Yoran
J'ai pas mal planché. Development Seed au premiers abords ont tendance à rajouter tellement de surcouche à Drupal que ça en fait vraiment peur. Mais pour avoir audité la quasi intégralité de leurs modules contrib, et pour avoir soumis certains patches, je peux dire après coup qu'en réalité ils emploient, la plus part du temps, de très bon paradigmes.
Le gros soucis avec leurs modules, c'est que les cycles de développement sont trop courts, et que parfois, en moins de trois mois on voit deux versions majeures du même module sortir sans même avoir de procédure de mise à jour fonctionnant, et ça, c'est plus grave car ça rend l'intégrateur/développeur trop tributaire de la volonté des auteurs de ces modules, et peut amener à devoir jeter pas mal de travail à la poubelle régulièrement.
De plus, ils ne publient comme documentation que ce qu'ils veulent publier, c'est à dire pas grand chose. Essayez de comprendre ce que fait réellement Spaces sans en lire le code, vous allez pleurer (ceci dit, une fois lu, on se rend compte que c'est un peu codé avec les pieds, mais que le paradigme est très bon, malheureusement fortement lié à leurs autres modules).
Pour ma part, au final, j'utilise beaucoup leurs outils, notamment Purl (très très bon module, en module d'API), un peu Strongarm (mais j'évite c'est quand même du gros hack, c'est plus pour faire le lien avec features), parfois Context (que j'essaye d'éviter car il rajoute un overhead énorme au temps d'éxecution, en pure intégration seulement), en gros j'utilise surtout leurs modules d'API qui ne bougent pas (Purl et Strongarm sont quand même fort pratiques, et peu couteux en performance). J'ai même développé un module (qui sera releasé dans quelques temps) qui emploie le même paradigme que Spaces, mais sans le poids des outils DS et CTools (ah mon dieu quelle horreur ce truc, je comprends pas que DS commence à l'utiliser dans tous leurs modules, c'est codé comme dans les années 80 et son auteur ne semble pas connaître réellement le PHP).
Hihi moi j'ai rigolé le jour où je me suis rendu compte que ctool, views et panels, mes 3 modules fétiches (ironie ;-) étaient développé de la même manière (assez d'accord avec ton analyse) par le même gars, qui ceci dit en passant a trouvé là un merveilleux psoeudo :)
Ca m'intéresse ce que tu dis sur contexte. Mis à par que ce module a un comportement un peu alléatoire sur ce projet justement (mais c'est peut-être lié à sa connexion avec Features), il me semblait bien que dans mon analyseur de perf il était assez présent, mais je n'ai pas encore eu le temps d'étudier cela de prés. Tu as plus de détail sur les problèmes de performances de ce module ?
Rah punaise, j'avais écrit un roman, et je l'ai perdu en appuyant sur une mauvaise touche, je recommence en synthétique:
Pour contexte, plusieurs choses:
Pour CTools:
Pour Views:
Et bé, pour le coup ça fait plaisir d'avoir un peu de factuel. Bon pour Context, cela confirme mon opinion de départ, doublé du fait que je n'ai pas bien compris la valeur ajoutée du zinzin. Si c'est juste pour coller des blocs aux bons endroits en fonction du chemin, un simple phptemplate_blocks dans un module custom fait la même chose en bien plus efficace.
Pour ce qui est de views, on est d'accord. Je suis rassuré, je pensais que c'était mon passé proche de dev java qui me faisait penser ainsi et que dans le monde PHP les choses n'étaient pas aussi carrées. Alors vu que même cette fois dans le principe même j'accroche pas (et dieu sait que j'ai essayé un paquet de fois), cela ne va pas me pousse à retenter l'expérience. Mais du coup, en te lisant, je comprends mieux que l'impression de maison du facteur cheval que j'ai en manipulant ce module. Je comprends mieux aussi, mais c'est plus grave, que le facteur cheval n'ait pas réussi à mettre en place un upgrade path propre de Views1 à Views2. Là tu me parles de Views3, et j'ai très peur...
Ma vie entière est orientée autour de l'encapsulation, des designs
patterns, et du SOLID principles, je peux pas supporter de voir
un code d'amateur être plus gros que le core de Drupal, qui lui même,
malgré son orientation procédurale, est bourré de design patterns plutôt
bien implémentés dans l'ensemble. Ce qui me tracasse le plus, c'est de
savoir que la pluspart des utilisateurs de Drupal l'utilisent et le
défendent pour son fonctionnel très riche (et qui faut l'avouer, est
conséquent et efficace).
Très honnêtement, si un jour le code de ce module se retrouve dans le
coeur, je me barre, je change de métier.
Ceci dit j'ai un esprit très (parfois trop) critique. Après avoir
regardé pas mal CCK, son design entier est orienté autour de l'array.
Et bien que PHP soit extrêment rapide sur les traitements des arrays,
ça rend son design plutôt obfusqué. Je pense (et attention, c'est un
point de vue, encore une fois beaucoup de gens me diront que je me
trompe et certains d'entre eux auront probablement raison) que pour un
module comme celui-ci, il aurait mieux fallu repartir de zéro sur la
base d'un design objet pour rentrer dans le coeur. La Field UI
est loin d'être parfaite, et vraiment dure à introspecter et comprendre
pour un développeur qui tente de rentrer dedans, et je pense que c'est
pas dû à son design ni aux performances de ses developpeurs, mais plutôt
à un refus de faire un pas en arrière, là ou l'inclusion dans le coeur
aurait été le meilleur moment pour le faire.
PS: J'ai vu que tu te décris en tant qu'expert J2EE, je suis de formation ingénieur J2EE avec (seulement) quelques mois d'expérience dans le domaine, la seule raison pour moi de ne y avoir choisit de faire carrière professionelle est que la porte d'entrée la meilleure était les SSII (et parce que je supportais pas Jonas et les EJB 2.0, bien que la version 3 de ces derniers était grandement meilleure, ceci dit j'ai jamais pu blairer les beans spring), ces fameuses usines à viande sans grand intérêt pour un employé. Ceci dit ce n'est pas forcément vrai pour y connaître des gens heureux. C'est assez étonnant que tu vendes en permanence le fait de faire du code custom pour autant de use cases récurrents, sachant que tu viens d'un milieu très orienté autour de la programmation par composant et la réutilisation du code, ceci dit, c'est un point de vue que je partage sur beaucoup d'aspects dans Drupal, même si je pense que la factorisation vaincra!
Bon allez j'ai assez pourri ta liste de commentaires, bonne soirée et à une prochaine.
J'ai parfois l'impression qu'il y a comme une religiosité qui frise l'anathème à l'égard de l'objet pour ce qui est de la communauté des développeurs Drupal. Un bon exemple de cet état d'esprit est ici : http://drupal.org/node/547518. Cependant je suis sûrement moins capable que toi de donner des leçons car PHP n'est pas ma langue maternelle, loin de là. Ce qui ne m'empêche pas de détecter certaines des aberrations auxquelles tu fais références lorsque je me retrouve à debugger du code de Views, au hasard.
je n'ai pas encore eu le temps de regarder comment était gaulé FieldAPI, mais pour ce qui est de CCK, il est certain qu'il y a une une marge certaine pour l'amélioration des performances. Je ne sais pas si tu as regardé la manière dont était agrégées les données en provenance de champs éclatés, mais ça vaut le coup d'oeil ;-) D'un autre côté lorsque l'on voit comment drupal maltraite ces pauvres bases de données (clefs étrangères ? késako ? ;-), ce n'est pas surprenant non plus.
C'est pas faux! Ceci dit avoir un schema éclaté n'est pas forcément synonyme de mauvaises performances, tout est une question de clé et de requêtes intelligemment écrites. Cependant créer des tables à la volée pour stoquer les informations d'un nouveau champs je trouve ça un peu immonde, en fait ce coupe tout le concept d'optimisation c'est que chaque node_save() va faire des delete et des save dans toutes ces dernières, si encore c'était découpé de telle sorte à ne faire que peu de requêtes, sur peu de tables à bon escient, ça serait probablement mieux...
Cependant, pour les foreign keys, ça bouge, Drupal 7 permet la description de ses dernières dans la schema API, même si il ne les exploite pas encore (quelle hérésie...).
Pour la maltraitance, ils font énormément d'effort, le pas franchis de Drupal 5 à Drupal 6 à été énorme. Et puis un SGBD, c'est fait pour être un peu maltraité :) Je dis bien un peu.
Et le PHP n'est pas ma religion, c'est vrai que je connais le langage depuis longtemps, mais ce qu'il manque à beaucoup de developpeurs, c'est d'oser aller regarder plus loin que le langage lui même, plus précisément connaître les implications de chaque syntaxe particulière sur la façon d'optimiser ou tout bêtement d'interprêter du compilateur intérprêteur PHP. Toutes les infos ou presque sont données dans le manuel PHP officiel, et dans quelques benchmarks à droite à gauche.
Si je devais avoir une religion concernant un langage, je voterais pour le C (j'adore les pointeurs), le C# (c'est vraiment un très très bon language, et encore je ne parle pas de l'API standard qui va avec, elle d'une qualité équivalente à celle du JDK de Sun) et un peu python (pour faire joujou, c'est un langage créé à des fins didactiques, quasiement aussi proche du langage à prototypage que du langage objet au final).
J'ai quitté le monde Java à peu prés pour les mêmes raisons qui t'ont saoulée à son entrée :) J'ai commencé Java à une époque où c'était nouveau et drole (un peu avant le jdk 1.0.2), et je l'ai quité lorsque ce n'était plus qu'un environnement de mormons plus occupés à inventer la nième couche_logicielle_passe-plat qu'à tenter de faire un peu d'innovation. Mais je vais peut-être m'y remettre avec Android qui me titille de plus en plus ;-)
Pour ce qui est des SSII, il faut juste choisir celle qui est à sa taille, se trouver un commercial fétiche et enquiller un maximum de missions pour s'en mettre plein la tête. Après, on a vu assez de cas de figure pour aller faire autre chose.
Mais pour répondre à ta question, pourquoi crois-tu que Drupal et son aspect modulaire m'a séduit ? Dans mes dépôts personnel à moi que j'ai, il y a un bonne cinquantaines de modules que j'utilise au grès des missions. Comme je le disais plus haut, Drupal est ambivalent et me permet soit de réutiliser, soit de créer lorsque c'est plus adapté. Mon opinion sur Views n'est donc pas représentative de la manière dont j'utilise Drupal, elle est représentative d'une certaine vision de l'efficacité. Pourquoi ajouterais-je un module "context" de 6496 lignes de PHP (je viens de compter) alors que je fais strictement la même chose avec en gros 100 fois moins de code en 10x moins de temps ?!? Ce n'est par exemple pas le cas de CCK qui lui me fait gagner du temps et du code.
En somme je suis pour la capitalisation, la mise en composant, mais d'expérience je sais qu'un bon projet c'est toujours 80% de réutilisabilité pour 20% de custom. Et c'est finalement aussi la morale du projet qui a donné lieu à ce papier, sauf que les 20% auraient pu être un peu mieux placés ;-)
Ouf alors, j'ai cru que t'étais une pourriture de développeur des années 70 :) Bon sur ce je te souhaites une bonne soirée, à une prochaine sur un thread chez toi ou ailleurs!
@yoran et @pounard : whoa merci pour ces échanges passionnants, j'apprends pleins de trucs !
@yoran :
"Et c'est peut-être cela qui me
géne le plus. Features veut répondre à deux besoins : encapsuler un
ensemble de fonctionnalités pour les déployer sur plusieurs sites comme
des modules, et permettre le déploiement de configuration sur un site
donné."
Je suis d'accord, y'a une confusion entre ces deux objectifs qui sont pourtant différents (l'un est plutôt orienté réutilisabilité, et l'autre orienté staging. Development Seed semble sous entendre que en faisant l'un, ça fait l'autre naturellement dans la foulée mais c'est pô vrai)
"A titre d'exemple pour étayer ce
second point, les vues intégrées par features ne sont pas stockées en
base, ce sont des vues par défaut. Ce qui veut dire qu'on repasse dans
le module de la feature à chaque fois que l'on utilise l'UI de views"
Heu je ne crois pas : c'est ton module (généré par features) qui implémente un hook de views pour générer les vues par défaut. Meme en désactivant features, tes vues fonctionneraient encore, c 'est indépendant (par contre c'est dépendant de views évidemment).
En revanche features implémente par exemple le même genre de hook pour cck; hors cck n'étant pas exportable, c'est features qui crée un pseudo hook simulant une "vie dans le code" des champs CCK (en réalité, juste un schéma de reconstruction lors du rebuild de la features, à coup de requetes sql). Donc là oui, features est un dépendance car il créer un hook custom pour enregistrer la définition de certains composants.
Mais pour autant que soit pour views ou CCK, le module features n'intervient pas ; c'est seulement lors des mises à jour de ta features que tu l'utilises, pour poussez la config dans le code.
"A titre d'exemple pour étayer ce
second point, les vues intégrées par features ne sont pas stockées en
base, ce sont des vues par défaut. Ce qui veut dire qu'on repasse dans
le module de la feature à chaque fois que l'on utilise l'UI de views"
erratum, j'avais mal lu, tu as raison. (j'avais lu "tu passes par le module features").
Mais c'est quand même pas vrai :-) : dès que tu modifies ta vue, elle retourne en base de données (avec le status "overriden"), et c'est l'objet en base qui a la précédence sur l'objet dans le code, jusqu'au moment où tu décides de faire un features-update pour mettre à jour ton code.
Maintenant passer par le hook c'est la condition sine qua non pour que la config soit exportée dans le code, faut bien aller le lire à un moment ou un autre...
Merci pour les précisions, c'est intéressant. Ce que je voulais dire (très mal dit) par dépendance, est que ton module featurisé est appelé systématiquement par l'UI de views, ce qui le ralenti un peu plus (et il n'a pas besoin de cela le bougre ;-).
En fait, après avoir passer une journée à remettre les features au carré dans ce projet (car bien évidemment les mecs utilisent features et comme c'est un peu lourd, le zappe pour le rush de fin de projet :/), je me rend compte que ce qui me pose problème avec Features depuis le début tient vraiment à cette ambivalence d'usage : capitalisation vs déploiement.
Si features avait été seulement un système de déploiement, le format d'échange aurait été totalement neutre et sans aucune interaction avec le système, sous la forme d'objets serialisés, de fichiers xml, etc. Le déploiement n'aurait du coup été qu'une re-importation de ces données en base.
Mais au lieu de cela, pour répondre à l'aspect "capitalisation", le format d'échange adopté est une génération de code actif trop lié aux modules visés (des hooks de views, une surcouche pour cck, etc.), et du coup le module "features" continue à vivre au delà de son déploiement. C'est contournable pour cck (iou les données sont stockés en base, on peut donc couper le module), mais pas pour Views (tu coupes le module, tu n'as plus les vues) ou StrongArm (même motif, même punition).
En bref, un features statiques "je me déploie et je me désactive" j'aurais trouvé cela nickel, mais le côté je reste dans le système et j'y fais des trucs historie de rajouter un peu plus d'entropie dans un système Drupalien qui l'est déjà pas mal, je trouve cela moyen. Cela induit d'une manière ou d'une autre des comportement chaotiques non prévisibles.
Ceci étant dit, ce module est pour l'heure la seule alternative de déploiement un tant soit peu crédible que j'ai trouvé, et je vais l'utiliser même si je continuer à trouver son aspect "capitalisation" dangereusement merdique.
"En bref, un features statiques "je me déploie et je me désactive"
j'aurais trouvé cela nickel"
oui mais alors tu perds un peu l'avantage d'avoir la config dans le code : pouvoir appliquer un changement juste en commitant les fichiers de local, sans opération nécessaires sur la BDD (ce qui tranquilise l'esprit sur l'intégrité des contenus). L'idée théorique de features c'est quand même de sortir la config de la BDD pour la mettre dans des fichiers, pour que la BDD soit uniquement destinée au contenu généré sur le site.
Ce que tu décris ressemble au fonctionnement du module patterns : un xml qui ne sert qu'à lancer des requêtes sql quand tu fais tourner le bouzin; et dont tu n'as plus besoin ensuite. Sauf que c'est juste une manière différente de continuer à mettre à jour la config en éxécutant du sql, tandis que features essaie de tendre vers une séparation entre le contenu qui continue à vivre dans la BDD, et la config qui vit dans le fichiers.
Je serais d'accord avec toi si les modules fonctionnait comme cela, mais ce n'est pas le cas. La majorité des modules puisent leur settings dans la base de donnée, et c'est bien tout le problème. Car de de deux choses l'une, soit on reste cohérent avec la "philosophie" de base de Drupal et on travaille en mode "configurateur", soit un hypothétique Drupal X se décide enfin à travailler proprement et imposer aux modules un stockage cloisonné pour les settings auquel cas features ne servira plus à rien ;-)
Maintenant tu viens de me mettre sur une piste excellement, le module patterns, je ne connaissais pas !!! Je vais explorer cela de ce pas, ça me plait énormement !!!
Oui je suis d'accord avec toi; mais comme je disais plus haut je suis content que le débat s'ouvre avec features et même (désolé) Ctools, qui a le mérite de montrer qu'il serait assez facile de créer une API normalisée pour que les objets fournis par les modules puissent vivre dans le code.
le module patterns est intéressant mais j'ai toujours pas compris comme exporter une vue avec ça : si il faut recréer entièrement à la main une représentation de l'objet vue en xml à la main c'est un peu galère xD
j'avais écris un petit truc au début de ma découverte de features et patterns
http://drupalfr.org/node/9349
y'a aussi une notice sur drupalistic
http://www.drupalistic.net/module/patterns
"Ctools, qui a le mérite de montrer qu'il serait assez facile de créer
une API normalisée pour que les objets fournis par les modules puissent
vivre dans le code"
Oui, ça s'appelle de la programmation (orientée) objet ;-)
Merci pour lie, liens ! je vais étudier cela de près, et si c'est concluant, je fais un retour :)
Nan des années 80 seulement ;-) De la très fière génération des 8bits ;p
Tsss, en 1985, les Amiga de Commodore étaient déjà en full 32 bits :)
85 c'est déjà la moitier des années 80 ça :) Et j'ai jamais eu de quoi me payer un amiga 1000 :)
J'ai commencé à l'amiga 500 et 500+, j'ai regardé tous les autres passer en versant une petite larme jusqu'au 1200, que je me suis empressant de monter dans une tour, en soudant des fils de l'alim AT sur la CM du pauvre 1200! Que de souvenirs.
Il est encore chez moi, je suis sûr que si je l'allume il marche encore!
D'ailleurs de mémoire, si je me trompe pas, l'amiga 1000 c'était le précurseur des 500 et 500+ (c'est le monde à l'envers!).
Salut Yoran !
Article très intéressant et agréable à lire reflétant la dure réalité !
J'en retire deux choses en plus de tes conclusions :
- Tu as du faire preuve de beaucoup de persévérance pour retrouver comment le site a été construit et si tu avais eu une petite documentation pour expliquer tout cela, ca t'aurais forcément fait gagner un temps précieux. Donc, que ca soit en configurant des modules existants ou en en codant de nouveaux, une petite doc est toujours un bon moyen de fournir un site maintenable...
- Comment en la personne précédente en est arrivée à une situation pareil ? J'ai ma petite idée la-dessus :
1 - Le commercial de la web agency fais signer un bon gros devis à son client en disant oui oui à toutes ses demandes.
2 - N'ayant pas la ressource pour développer en Drupal, elle sous-traite le boulot pour moitié moins que le devis.
3 - Le sous-traitant regarde vite fait le cachier des charges et se dit que Drupal doit être bien fait pour cela.
4 - Chacun ensuite se tire la couverture à lui : Le client pour avoir ce qui est demandé, la web agency pour pas mobiliser trop de temps pour ses chefs de projets, le sous-traitant pour éviter de passer un 41iem jour de travail là ou il en devisé 10. D'où, discussions sérrées, négotiations sur le cahier des charges,
5 - Le client en a ras-le-bol de la web-agency et fait appel à toi pour une petite évolution
Je pense que je ferais une bonne madame soleil...
LOOOOL Le client en question qui lit les commentaires doit être aussi mort de rire que moi. Tu as 90% de bon dans ta prédiction. Pour corser la sauce rajoute une pincée d'offshoring et deux prestataires outre-mer coup sur coup ;-) Mes félicitations à Mme Soleil ;-)
Laisse dire et laisse faire : concernant Drupal, je n'ai jamais vu un code aussi propre et une structure aussi simple que sur le projet sur lequel nous avons travaillé ensemble. A me décourager de retravailler avec d'autres, où le theming se conçoit comme une boucle sans fin de Mac-Gyverisme à la sauce A-team. Alors je ne maîtrise peut être pas toutes les références de ton article, mais quelque chose me dit que tu dois être dans le vrai... en tout cas le vrai pour moi :)
Et j'ai bien rigolé surtout :)
merci Vincent, c'est vrai que ce projet fût bien fun :)
@Yoran
J'arrive plus du tout à comprendre le thread, apparament ça indente pas à plus d'un niveau ça rend la lecture un peu obfusquée :)
Ahah, je crois qu'on est tombé sur un cas limite de Drupal là... C'est normal si les 3/4 des commentaires ont disparu?
Va falloir aller dire aux mainteneurs du DB layer que les transactions, c'est important.
Ça pue l'édition concurrente qui à fait se chevaucher des écritures en base (ou alors c'est un simple bug graphique (ou alors tu as modéré)).
Le coup de l'indentation c'est un peu la quadrature du cercle, en l'activant pour de vrai tu finis par avoir des conversations qui commencent à l'extrême droite de l'écran :) Et en faisant du pur "à plat", c'est pas pratique, j'avais donc patché pour obtenir la voie du millieu :)
Mais non, ça pue juste le drupal qui manque d'une bonne couche de conception avec des liens sur les commentaires qui ne fonctionnent plus dés-lors qu'il se met à les paginer :) Là j'ai mis la pagination à 300, ça devrait nous laisser de la marge ;-)
Arf ok, c'est vrai que j'utilise peu la pagination des commentaires, ça me fait pas peur d'en afficher 300 sur la même page :)
Bon j'espère que ça va être plus lisible comme cela. J'ai remonté la limite à 300 et j'ai aussi patché le module comments pour trier de manière un peu plus logique les posts. Avis bienvenus :)
merci pour cet article, ça m'a occupé un peu pendant mon stage.
je pense que les developpeur de la boite apprendraient des choses en lisant cet article :)
Publier un nouveau commentaire