Drupal, Views et les dangers du clickodrome....
Je l'avoue bien volontier, j'ai mis du temps à reconnaître que CCK était un outil réellement indispensable. Il n'y a que les imbéciles qui ne changent pas d'avis dit le dicton. Mais s'il est un module qui continue après tout ce temps à me laisser comme une poule devant un couteau, c'est bien Views. Et encore, c'était avant d'étudier d'un peu plus près les performances de la bête...
Cas d'école
Raison de mon énervement passager, une vue prise "au hasard" parmi plus de 140 (ouch!) sur un projet qui souffre de quelques lenteurs... Un vue toute simple présentée sous la forme d'un bloc contenant une liste elle-même issue d'une pauvre requête sensée renvoyer 1 enregistrement avec comme critères un type du noeud, une date CCK dans le passé et un tri par date décroissante. Pas le Pérou donc, et pourtant il faut pas moins de 230ms à Views pour générer cette petite vue. Relativement lent donc au regard du travail effectué, ce sera donc le cas pratique que j'utiliserais pour comprendre ce qui se passe.
La requête SQL
Pour voir un peu la tête de la requête générée, il est possible soit d'utiliser l'aperçu de Views2, soit, plus simplement, de mettre des traces en sortie de db_query. Voilà ce que cela donne :
SELECT
DISTINCT(node.nid) AS nid,
node_data_field_contenu_1.field_contenu_1_nid AS node_data_field_contenu_1_field_contenu_1_nid,
node.TYPE AS node_type,
node.vid AS node_vid,
node_data_field_contenu_1.field_contenu_2_nid AS node_data_field_contenu_1_field_contenu_2_nid,
node_data_field_contenu_1.field_contenu_3_nid AS node_data_field_contenu_1_field_contenu_3_nid,
node_data_field_contenu_1.field_contenu_4_nid AS node_data_field_contenu_1_field_contenu_4_nid,
node_data_field_contenu_1.field_contenu_5_nid AS node_data_field_contenu_1_field_contenu_5_nid,
node_data_field_contenu_1.field_contenu_6_nid AS node_data_field_contenu_1_field_contenu_6_nid,
node_data_field_date.field_date_value AS node_data_field_date_field_date_value
FROM node node
LEFT JOIN content_field_date node_data_field_date ON node.vid = node_data_field_date.vid
LEFT JOIN content_type_une node_data_field_contenu_1 ON node.vid = node_data_field_contenu_1.vid
WHERE
((node.TYPE IN ('tagazok')) AND (node.STATUS <> 0))
AND (DATE_FORMAT(STR_TO_DATE(node_data_field_date.field_date_value, '%Y-%m-%dT%T'), '%Y-%m-%d\\T%H:%i:%s') <= '2009-06-30T00:55:00')
ORDER BY node_data_field_date_field_date_value DESC
LIMIT 0,1Requêtes à la Views
Avouons déjà que c'est tout de même très moche, et à ceux qui me dirait "mais c'est pas grave, on le voit pas", je répondrais "le code HTML de MS-Word aussi personne ne le voit, pourtant y'en a plein que ça défrise...".
Mais au delà de ces considérations esthétiques propres à chacun, voyons ce que nous avons dans notre besace à la Prévert:
- Un aliasing inutile de tous les champs (jusqu'à un node node bien mignon)
- Une condition de barbare pour sélectionner une simple date dans le passé.
- Un recherche dans un ensemble d'une seule valeur (node.type in ('tagazok')).
- La remontée d'une tripotée de champs sans intérêt alors que seuls les field_contenu_XXX étaient demandés.
- Un Distinct qui fait joli avec le limit 0,1.
Nous ne pouvons pas faire grand chose sur la condition barbare, mais voyons à quoi ressemblerait un code SQL débarrassé du reste de joyeusetés. Il ne s'agit pas vraiment d'optimisation mais juste d'un petit nettoyage printanier.
SELECT b.* FROM node n
LEFT JOIN content_field_date a ON n.vid = a.vid
LEFT JOIN content_type_une b ON n.vid = b.vid
WHERE
n.TYPE='tagazok' AND
n.STATUS <> 0 AND
(DATE_FORMAT(STR_TO_DATE(a.field_date_value, '%Y-%m-%dT%T'), '%Y-%m-%d\T%H:%i:%s') <= '2009-06-29T18:38:49')
ORDER BY a.field_date_value DESC
LIMIT 1requête à la main
MySQL le fautif ?
Notre premier test consistera donc à voir si les performances diffèrent significativement entre des deux requêtes. Pour ce faire, j'ai simplement crée un script Drupal procédant à 1000 exécutions de chacune des deux requêtes :
| Requête | Itérations | Temps |
|---|---|---|
| Views | 1000 | 0.54 |
| Manuelle | 1000 | 0.47 |
Déjà rien que là, on a gagne 13.3% de performances ce qui est assez inquiétant. En effet, d'un point de vue purement sémantique, les deux requêtes sont tout de même très proches l'une de l'autre, et les bases de données sont sensées gommer ce genre de détail à travers leur module d'optimisation. J'aurais donc tendance ici à aller taper sur l'optimisateur de requête de MySQL qui semble bien en deçà de ce que l'on a l'habitude de trouver sur une base Oracle ou même PostgreSQL.
Le choix des types de champ
Ceci étant dit, nous parlons là de 13% et cela n'explique pas que le rendu soit si lent. ce qui n'est rien en comparaison de ce que nous coûte la condition barbare. En effet, si l'on retire cette horreur, c'est un gain de 39% que nous obtenons...
Ici Views n'est qu'une victime d'un petite désastre vienant de CCK. En effet, pour gérer les dates dans les contenus, CCK implique l'utilisation du module
Du coup, en choisissant le type Date pour un champ, on oblige chaque requête devant implémenter une condition sur ce champ, à jongler entre la représentation textuelle de la date et sa représentation "entière". Des conversions qui ont un coût non négligeable à additionner à celui de devoir travailler sur un plus grand volume de données.
Le type "Date" pour un champ CCK est donc à éviter à tout prix car sinon au profit d'un DateStamp.
Le coût du click
Mais le plus intéressant n'est pas encore là. Pour avoir une vision complète, il nous faut comparer cette fois les vitesses de rendu du bloc views, celui impliqué par en gros 20 lignes de PHP dans un module.
| Rendu de bloc | Itérations | Temps | select | delete | insert | update |
|---|---|---|---|---|---|---|
| Par Views | 100 | 2.31 | 53 | 10 | 10 | 20 |
| Par un module custom | 100 | 0.07 | 100 | 0 | 0 | 0 |
Notez pour l'échelle de grandeur, que le premier teste (SQL) a été répété 1000 fois pour obtenir ces temps, et seulement 10 fois pour ceux portant sur la génération des blocs. Et là nous sommes juste à 96.4% de performances supplémentaire en faveur de nos 20 lignes de PHP.
Alors pourquoi ? Une partie de la réponse se trouve dans les colonnes suivantes. Disons que pour une simple liste générer 5.3 requêtes SELECT, 1 requête DELETE, 2 requêtes UPDATE et 1 requêtes INSERT, ne peut pas, avec la meilleur bonne volonté du monde, donner de bons résultats.
C'est un peu la quadrature du cercles cette histoire, il faut des requêtes pour remonter les modèles de vues stockées en base, qui vont permettre à grand coups de hooks et de plugins (et donc de temps CPU), de générer une requêtes SQL que l'on va, à grand coups de hooks et de plugins formater en une simple liste à puces. Et comme tout ceci prend du temps, on rajoute en plus des couches de cache pour cacher la misère (les INSERT/DELETE/UPDATE). Tout cela pour s'éviter de rédiger 20 lignes de PHP, c'est un peu dur.
Le cache de block ne sauvera personne
Après j'en entend qui disent "pas grave, y'a le cache de blocks, et puis si c'est pas suffisant, y'a le cache de page". Certes, mais déjà le cache de page ne fonctionne que pour les visiteurs anonymes et celui de block fait ce qu'il peut avec les authentifiés.
Ensuite les caches de bloc ET de page sont virés dès qu'un contenu et/ou commentaire est ajouté. Autant dire que sur un site à gros trafic il ne faut pas trop y compter. Si si, je vous assure... Ligne 776 de comments.module :
// Clear the cache so an anonymous user can see his comment being added.
cache_clear_all();
Et si l'on regarde la fonction cache_clear_all() :
if (!isset($cid) && !isset($table)) {
// Clear the block cache first, so stale data will
// not end up in the page cache.
cache_clear_all(NULL, 'cache_block');
cache_clear_all(NULL, 'cache_page');
return;
}
Et voilà...
Conclusion
Autant Views est clairement plus lent qu'un travail fait proprement à la main, autant il ne faut pas non plus jeter le bébé avec l'eau du bain. Pour de petits sites tranquilles ce module permet à un non-développeur de fabriquer sans connaissance particulières ses propres listes, flux, blocs, etc... Maintenant pour un site "pro", il faut clairement réfléchir un peu avant de coller cela sur une home-page.
Pour le reste, Views est une redoutable documentation interactive permettant en quelques clicks de comprendre la construction de requêtes un peu tordues du genre "comment avoir la liste des contenus ayant les meilleurs notes et écrits par mes amis". Rien que pour cela je lui suis redevable :-)
"Un recherche dans un ensemble... d'une seule valeur (node.type in ('tagazok'))"
ça normalement avec un SGBD digne de ce nom ça n'a pas d'impact.
Moi ce qui me choque dans cette requête, c'est la condition sur DATE_FORMAT(STR_DATE()) que je soupçonne être responsable d'un scan complet de la table lors de l'exécution. Un petit EXPLAIN serait intéressant. Sinon c'est vrai que le "FROM node node" est très marrant :)
Ban, j'ai tenté une session de rattrapage pour ce pov' Views en allant chercher la "vraie" requête qu'il faut en base. C'est un peu mieux que ce qu'il prétend sur l'interface, il y a bien un LIMIT. Du coup les perfs c'est légèrement meilleur que pour le premier test. En revanche, j'ai un peu halluciné lorsque j'ai rajouté des compteurs d'INSERT/UPDATE/DELETE/SELECT. On marche un peu sur la tête là...
Sinon, pour le coup du "in", lorsqu'il s'agit de mySQL, je reste méfiant. Si tu regardes ma requête faite "à la main" et la version "views", il n'y a rien que l'optimisateur d'un Oracle ou d'un postgreSQL n'aurait remis proprement à plat. Le cas des alias est assez flagrant car rien qu'en faisant voler ces "longueurs" on gagne en performances. En somme tout doit tenir dans ton "un SGBD digne de ce nom" ;-)
Pour le coup de la condition barbare, moi ce qui me choque c'est que DATE API trouve malin de fournir des dates stockés sous forme de chaîne de caractère... On peut critiquer le choix d'un timestamp (ce que Drupal utilise partout) au profit d'un TimeDate propre à la base, mais une chaîne, c'est totalement indéfendable. Et encore là, il n'y a qu'une condition, je n'ose pas imagine ce que cela donne avec un ou deux intervalles de dates... Et c'est là qu'on touche au gros malaise avec CCK, pas possible de migrer les champs d'un type à l'autre sans se frapper la moulinette qui va bien...
En effet, ça n'est pas nouveau : le module Views est fortement critiqué pour 2 choses : son UI flippante et ses performances médiocres.
Ton analyse est très intéressante, mais quelles pistes d'évolutions/corrections donnerai tu au(x) maintainer(x) ? Ce module est génial dans le principe et dans l'utilisation (une fois l'interface amadouée, on est d'accord) : alors que pourrions nous faire pour le transformer en réelle killer app ? :-)
Tu vas dire que je prêche pour ma paroisse :) Mais si tu es mainteneur sur un gros projet, j'ai du mal à envisager son équipe sans un développeur capable de coder une requête SQL et les 10 lignes de PHP qui vont avec. Si c'est un moindre projet, les performances de Views ne sont en soit pas un problème.
Sinon pour ce qui est des pistes d'évolution, franchement je n'y crois pas beaucoup. Views est en gros un modeleur de requête comme tu en as dans Access depuis plus de 10ans. Cela n'a jamais fait de miracles ni remplacé une requête à la mano, mais ça fonctionne. Pour views, tu rajoutes en plus la complexité des modules contributions avec chacun leur schéma de table. Là ça devient pour le moins coton...
Maintenant pour être constructif, ce que je verrais bien dans Drupal c'est :
- un "DataSource API". L'idée est de pouvoir ajouter des sources de données prise en charge par des modules implémentant l'API (ex. datasource_sql, ou datasource_rss, etc..). Le mainteneur peut ainsi créer les datasources qu'il désire et pourquoi pas les combiner à la yahoo pipes.
- un "Presentation API". L'idée pour le mainteneur est de faire créer des connexion entre une source de donnée, et un module de "presentation" (ex. presentation_bloc, presentation_rss, presentation_page, etc.).
En adoptant ce principe, Views n'est plus qu'une interface graphique permettant de simplifier la génération de requêtes SQL. Le développeur peut ensuite optimiser cette requête pour un datasource donné. Il peut aussi créer des présentations "custom".
Bref, avec du temps, on en fait des choses :) Moi pour l'instant je me suis fait un module d'une bêtise grave, façon "nouveau type de contenu" avec un champ supplémentaire pour coller une requête SQL. Avec cela je génère toutes mes listes et je n'ai pas les contraintes de Views comme le fait de ne pas pouvoir appliquer le module printer (et donc les sorties pdf). Et ça répond à 99% de mes besoins :)
Bonjour et merci pour cet article très intéressant.
Utilisateur de Drupal depuis peu, je me suis rapidement rendu compte des limites de Views pour effectuer des requêtes "tordues" (du style trier une table selon un champ pour en extraire les 10 premieres entrées, puis trier ces 10 entrées selon un autre champ => je ne vois pas vraiment comment faire avec le module)
Indépendemment de la plus grande facilité de coder ça "à la main", le critère de performance que vous évoquez içi conforte largement mon idée de me passer de views.
Cependant je me demande quelle est la méthode la plus efficace pour insérer son propre code, mes recherches me donnent des résultats différents : certains ne jurent que par la création de modules dédiés, ce qui me parait très lourd. La solution que vous présentez - nouveau type de contenu avec un champ pour la requête - me parait idéale.
Quels sont les inconvénients de cette méthode ? (pourquoi "bêtise grave"?)
Merci d'avance
Pour médiapart j'ai expérimenté plusieurs méthodes.
1/ L'approche par module pure est effectivement trop lourde. Le module doit être envisagé comme une unité de sens, ce qui entraîne une multiplication peu productive des petits pains ;-)
2/ L'approche "type de contenu liste" marche pas mal du tout mais est un peu restreinte en terme de formatage des résultat sauf à étendre exagérément le paramétrage du dit type de contenu.
3/ L'approche "librairie" est celle que j'ai retenue. J'ai un module "datasource" qui contient une série de fonction de haut niveau (un datasource qui contient la partie SQL, les paramètres, la pagination, etc) me permettant de construire des requêtes génériques et d'en exploiter rapidement le résultat (ex. Créer un flux RSS ou une carte Google à partir du datasource XXX). Avec cette aproche, et en utilisant comme base les requêtes gracieusement fournies par les anciennes vues views, on a converti très rapidement les centaines de vues du projet.
La "bétise grave" fait ici référence à la simplicité du module (3). personnellement je n'ai pas vu d'inconvénient à cette méthode si ce n'est savoir coder en SQL et avoir une bonne connaissance du schéma de base de données.
excellente analyse, mais la réalité est là : Views est absolument indispensable ... enfin, disons que sur tous les projets web en Drupal que j'ai monté, j'en ai toujours eu besoin à un moment ou à un autre, alors ... peut être que la solution provisoire est d'optimiser le serveur pour augmenter la performance des requêtes (ce que tout le monde ne sait pas faire, moi le premier) ?
Je ne vois pas bien en quoi il est indispensable. Drupal a une API super bien fichue qui perment en 20 lignes (10 c'était un peu exagéré) de faire exactement la même chose qu'un bloc views avec en gain la vitesse, et le contrôle.
function mon_module_block($op = 'list', $delta = 0, $edit = array ()) { switch ($op) { case 'list' : return array ( 'ma_liste' => t('Ma liste'), 'cache' => BLOCK_CACHE_GLOBAL ); case 'view' : if ($delta == 'ma_liste') { $cursor = db_query("SELECT nid FROM node where bla bla"); while ($node = db_fetch_object($cursor)) { $node = node_load($node->nid); $output .= "" . l($node->title, "node/" . $node->nid) . " ";
}
return array (
'subject' => t("Ma list"),
"$output
" ); } }Alors je sais pas, c'est peut-être une question de personnalité mais je préfère passer un peu de temps à comprendre cette API qu'un temps clairement équivalent à capter l'IHM de Views :-)
Effectivement le bout de code fait autant l'affaire et a l'avantage d'être propre...
Toutefois, pour moi l'intérêt de views se révèle plus dans l'affichage sous forme de tableau avec la gestion de la pagintation, les headers de colonnes cliquables pour trier la liste, les critères de recherche...
Et là tu ne me feras pas croire que tu peux faire cela en 20 lignes de codes (ou alors je suis passé à côté de quelque chose)!
@+
Mais quant je dis que Drupal est un framework de malade ;-)
Alors tu disais ? tableau, pagination, header cliquables pour les tris...
function mon_module_tablea_callback() { $header = array( array('data' => t('Title'), 'field' => 'title', 'sort' => 'asc'), array('data' => t('author'), 'field' => 'u.uid')); // Requête triées en fonction de l'en-tête $query='SELECT r.*,u.* FROM node n INNER JOIN node_revisions r ON r.vid=n.vid INNER JOIN users u ON u.uid=n.uid WHERE n.promote = 1 AND n.status = 1'; $result = pager_query($query.tablesort_sql($header), 10); // Population du tableau $rows=array(); while ($node = db_fetch_object($result)) $rows[] = array($node->title, theme('username', $node)); // Theming du tableau et du pager return theme('table', $header, $rows).theme('pager', NULL, 10, 0); }voilà, voilà... :) 20 lignes tout rond, commentaires, déclaration de callback et lignes sautés comprises. Pour les critères de recherche faut juste un chtit formulaire en plus, rien de bien sorcier.
En plus, comme tu le vois, une bonne partie de ce code est totalement générique. Tu peux ainsi assez facilement faire une fonction qui prend en paramètre le header et la requête pour fabriquer la page au complet. Il y aurait juste à améliorer le header pour ajouter le thème à utiliser pour formater la donnée de la cellule (si ce n'est pas déjà une fonction existante, je n'ai pas vérifié). C'est d'ailleurs en gros ce que fait views, on zappe juste l'aspect paramétrage qui lui coûte du temps.
Mais entendons nous bien, s'il fallait maîtriser les API drupal pour l'utiliser, ça lui couperait un large publique, et en cela Views est parfait. Mon seul point depuis le début est que dans le cas d'un site qui nécessite du temps et des moyens, faire l'économie d'un développeur et utiliser views partout est un peu dommage. La seule chose que je cherche à montrer ici c'est que c'est faisable, pas terriblement compliqué, très performant et qu'en plus cela démontre la puissance du framework.
Trop la classe cette solution!
Je suis complètement convaincu maintenant.
Je préfère autant avoir un module permettant d'avoir une degré de custo maximum en utilisant un code simple et propre plutôt que perdre du temps à comprendre l'UI de views qui est loin d'être intuitive et contestable en matière d'ergonomie (forcément quand on veut atteindre un grand degré de liberté, on perd sur la simplicité). Quid de la pérennité des 2 solutions sur un changement de version de Drupal?
Tu m'en vois ravi :)
Pour le degré de pérénité, je vais juste prendre un exemple. Lorsque Views est passé de la version 1 à la version 2, la conversion n'a pas pu être réalisée de manière automatique lors du processus de mise à jour du module. Du coup, pour un site utilisant une centaine de Drupal 5/views version 1, la migration views2/Drupal 6 a consisté à convertir à la manu (avec l'utilitaire fourni par Views2) les 100 vues une à une, en vérifiant à chaque fois que ça fonctionnait, et en devant changer des tas de trucs qui ne passaient plus. En gros, une semaine de boulot.
Dans le même esprit, avec un module qui contiendrait 100 vues écrites à la mains (ce qui serait idiot, cf factorisation de code), dans l'éventualité improbable ou l'API change radicalement (généralement c'est un paramètre en plus ou en moins), je te laisse imaginer le temps que ça prendrait avec un bon éditeur.
Et ceci sans compter qu'une fois que tu as migré tes vues sur ta machine de dev, faut refaire les exports/imports sur la machine de prod en priant St Gretta que tout passe correcte. Tandis que dans du code, ma foi...
Maintenant cela ne m'empêche pas d'utiliser Views à haute dose, pour me générer des requêtes un peu tordues entre les données de plusieurs modules, que je colle ensuite après nettoyage dans un module :)
Je suppose que tu as lu le post d'Earl...
http://www.angrydonuts.com/views-panels-economy-of-front-end-code-and-cl...
En fait non, mais je ne suis pas loin d'être d'accord avec lui. Pour ce papier (le mien :), je part de ce constat sur la tête de cette pauvre requête pour arriver finalement à un problème beaucoup plus grave, celui de la lourdeur du module lui-même. Peut-être n'est-ce pas assez clair dans mon discours.
Au fond, une requête super-optimisé ne ferait gagner que 10 à 15% de performance sur une des dizaines de requêtes effectués pour construire la vue. Autant dire des cacahouètes. Le problème n'est donc pas moins la requête que les requêtes qu'il faut pour arriver à la construire, et les traitements qu'il faut pour en faire son rendu final. Finalement c'est là que le bas blesse avec ce module, et c'est effectivement le même problème avec Panels.
Maintenant pour revenir à la requête en elle-même, au fond le vrai problème ici est le pitoyable moteur d'optimisation de mySQL. Je peux te garantir que cette même requête exécutée au hasard sur une base Oracle, n'aurait donné aucune différence de performance avec ma requête à la main.
Hello Yoran !
Sur les mesures je suis complètement d'accord, d'autant que comme tu le soulignes le framework de Drupal soulage très largement le codage d'une requête sql. De toute façon le principe de faire des requetes sql pour construire des requêtes sql refroidit tout de suite ...
mais on pourrait faire le même reproche à l'égard de Drupal en général et de n'importe quel CMS : Le premier site que j'ai fait (tout en php) à l'époque avait besoin d'une seule et unique requete sql pour afficher toutes les données (ma première jointure de table, ce fut un moment d'émotion). En passant le même site sous un CMS (modx) je suis passé entre 50 et 120 requetes sql : ça déprime quand on essayait de n'en faire qu'un à trois par pages max...
Les philosophies ne sont pas les mêmes. Lorsque tu fais un logiciel à façon, comme ton premier site, on ne gère pas les milles choses qui sont un standard dans Drupal. La bonne question est alors "en as t'on besoin ?". Tout est une question de temps au fond. Si on traçait deux courbes, avec en ordonnée le nombre de fonctionnalités à développer, et en abscisse, le temps pris pour les implémenter, ta courbe "mon site en PHP" évoluerait en exponentiel, celle d'un CMS, évoluerait en linéaire. Alors jusqu'à ce qu'elles se croisent, évidement tu as tout intérêt à faire un développement à la main car un tel site ira TOUJOURS beaucoup plus vite qu'un CMS quel qu'il soit, mais une fois passé le croisement, c'est de moins en moins possible.
Ce même principe est applicable entre deux CMS, celui qui est le moins évolutif gagnera toujours en vitesse sur celui qui est plus modulaire, mais les courbes fonctionnalités/temps de dev vont évoluer de la même manière.
Pareil encore si on parle d'un module comme Views et de faire ses requêtes à la main, à part que là on réduit la courbe à un sous-enseble fonctionnalité. Mais j'ai bien conscience que si l'on a 20 jours pour coder 1000 vues, ça tiendra jamais sans Views, mais Views sera toujours plus lent qu'un module à la mano.
En somme faire 3 pages max en Drupal, c'est peut-être pas la meilleur des choses à faire :)
Bonjour,
Quel plaisir de retrouver votre site ou les informations sont précieuses ;) d'autant qu'il semble avoir été remis à jours ces derniers temps.
Pour ce premiers com, je viens vous demander le lien pour télécharger les icônes que vous utilisés sur ce site pour les avatars et autres mise en pages. J'avais vue passer un lien sur l'un de vos commentaires mais je ne sais plus le retrouver.
J'avais trouvé cette bibliothèque (que j'avais téléchargée) plutôt complète mais un formatage malencontreux... Pfttt... Erf.
Merci d'avance.
Une partie vient d'ici : http://gnome-look.org/content/show.php/buuf+icon+theme?content=44539
Pour le reste, cela vient des thèmes Oxygen pour KDE 4 et Tango qui ont le mérite de fournir du SVG. Pour les liens, il faut chercher sur kde-look.org.
Hello,
Discussion fort intéressante.
Quelques petites remarques en passant, même si elles arrivent un peu après la bataille :
- La question des perf est-elle encore pertinente ? Ne faut-il pas utiliser Drupal comme un "assembleur" de pages et s'en remettre à d'autres (proxy, cache, etc.) pour servir ces pages aux utilisateurs ?
- C'est bien que tostinni ait mentionné le post de merlinofchaos : compte tenu de tout ce que Views est capable de faire et de tous les scénarios qu'il doit accommoder, le résultat ne peut pas être aussi clean qu'une requête maison, dédiée à un cas précis. Moi, il y a des tas de trucs que Views fait que je me passe volontiers de coder, pas parce qu'il le fait mieux que moi, mais simplement parce qu'il n'y a aucune valeur ajoutée dans un codage maison.
- Tu soulignes que ce n'est pas tant la requête que la lourdeur de la machinerie Views qui plombe les perfs. Que penses-tu dans ce cas de faire un copier-coller de la requête générée par Views pour la thémer ensuite manuellement ? (technique que j'ai vu mentionnée dans plusieurs "case studies")
- Pourquoi pas de theme('item_list', $items) dans le premier exemple ? :)
Au final, pour moi, la question est : où placez-vous la valeur de votre application/site ? Dans les performances ou dans les fonctionnalités ?
Bien-sûr, je ne parle pas du cas où les performances dégradent tellement l'expérience que le site perd toute sa valeur (il paraîtrait même que quelques millisecondes de perdues dans le chargement d'une page Amazon feraient perdre des milliers de ventes...). Je parle d'un scénario où on a des deadlines serrées et où il est peut-être plus important de se concentrer sur les fonctionnalités qu'on développe que sur le fait de gagner un peu de temps.
Vincent
Salut Vincent :)
Je me souviens d'une longue discussion en bagnole sur ce sujet. Tu ne peux pas te reposer sur une infrastructure pour gagner en performance. En tout cas pas dans tous les cas. Si tu prends un site Drupal fortement authentifié et donc fortement customisé pour chaque utilisateur, que deviennent tes caches, proxy & co. Ils ne font qu'aider et tu va devoir démultiplier ton infra technique pour suppléer un manque d'intelligence dans le code.
Je ne dis pas le contraire et je ne cherche pas à noyer le bébé avec l'eau du bain. Si tu n'as aucun besoin de performances, pourquoi pas. Et cela dépend aussi de ta rapidité à coder. J'ai eu le cas récemment de Views+Calendar. Sérieusement, le temps que je comprenne comment cette usine à gaz fonctionne pour un 80% du besoin, j'ai eu plus vite faire de me faire mon pauvre calendrier qui réponde à 100% du besoin.
Hé bé, tu as lu ma conclusion ou pas ? :) C'est très exactement l'usage que je lui trouve :) Je vais même aujourd'hui un peu plus loin en bossant sur un module "datasource" qui me permet de faire en gros la même chose que views, mais avec une boite à outil pour développeur. Je teste cela avec un de mes clients et on arrive à générer les 3/4 des vues existantes en 10 minutes pièce.
Arf, tu me fais gagner encore quelques lignes là ;-)
Le cas Amazon est assez flagrant d'un client que l'on aura jamais ni toi ni moi. J'ai vu de manière assez proche la machinerie qu'ils ont pour avoir de tels temps de réponse, autant te dire que tu n'a JAMAIS un seul élément de page qui soit calculé en temps réelle. Là ce sont de armées de caches qui bossent et derrière une application en Java/J2EE.
Maintenant pour les sites de tailles moyenne sur lesquels je bosse, la performance de Drupal est un point extrêmement problématique. Je n'en suis pas venu à me lancer dans cette "étude" pour la beauté du geste ou une quelquonque orthodoxie. Et là Views est sincèrement une vraie plaie.
Maintenant s'agissant de petits sites au thème relativement uniforme, fortement anonyme et sans communauté/réseaux sociaux, je suis assez d'accord, Views peu faire gagner plus de temps qu'il n'en fera perdre.
Mon seul objectif avec ce papier est un gros "faites gaffe à ce que vous faites et utilisez le en connaissance de cause". En aucun cas je ne benne l'outil.
N'oubliez pas une chose essentielle ! Sur un site à gros traffic il faut considerer la chose sous l'angle budgetaire. En effet Views, offrant un haut niveau d'abstraction (le code de views est une pure merveille, pour peu qu'on met les mains dedans), est plus lent qu'une requete ecrite de maniere spécifique.
Mais Views n'est pas qu'un constructeur de requetes ! Views offre surtout la puissance des arguments / filtres récupérables depuis l'URL, c'est aussi une maniere unique de themer, c'est aussi l'intégration avec Panels & Services...
Donc je dirais sur un gros projet dont ont devra assurer la maintenance, Views est une pure merveille.
Enfin il faut aussi savoir optimiser Views, dans le choix des champs, les relations & co (exporter le code des views depuis la base)...
Sous l'angle budgetaire prenons un cas concret :
Si on a besoin de 10 jours de dev de plus ca coute au client entre 4000 et 6000 euros et sans compter le temps de la maintenance, évolutions et modifications... Qui sur un gros site de contenu peut représenter beaucoup.
Acheter un serveur supplémentaire coûte dans les 3000....
Je connais de près un bon exemple où ce genre d'âneries a conduit à acheter plutôt 5 serveurs.
On peut arriver à un tel niveau d'inepties (views + cck c'est un must). Moi qui ai été à l'école Allociné, je me marre juste à l'idée de montrer ça à l'un de mes directeurs techniques de cette époque. Je me serais fait dépecer si j'avais ne serait-ce que proposé un outil de ce genre (même si il n'y a rien de ce genre là-bas) :p
Sans rire c'est une vraie usine à gaz.
Donc pour des usages limités et dans des contextes particuliers je ne trouve pas ça idiot.
Mais sur un gros projet, je crois que Yoran me rejoint sur ce point, c'est une bêtise. Si sur un gros projet on a pas de ressources compétentes dédiées ça me paraît dingue. Par ailleurs des views qui seraient l'équivalent de 10 jours de boulot je demande aussi à voir. Soit c'est vraiment un gros machin compliqué et views me paraît encore moins adapté, soit on a une équipe pas super efficace.
Avec Yoran nous avons remplacé toutes les views d'un gros site par un mécanisme de son cru. Je ne sais plus combien Yoran a mis pour coder le moteur à la base de l'opération mais ça doit être une petite poignée de jours (1 ? 2 ?) ensuite il suffisait de reprendre les requêtes, les optimiser, et les recoller dans cet outil. Et on a remplacé TOUTES les views.
Maintenant tant qu'il y a des boîtes qui ne savent utiliser que Views (j'en connais une qui fait payer plus en utilisant Views partout que n'importe quelle autre en passant plus de temps à coder à la main !) ça fera du travail pour les Yoran de la place (et les gens comme moi).
Marc.
Salut Marc :-)
Le module DataSource doit en crois peser 2jh pas plus. Et la centaine de vue ont été transposée en une dizaine de jours (au fil de l'eau donc en charge, je dirais 3jh).
Bon article, je suis tout à fait d'accord, views génère des requêtes absolument immondes, mais je suis pas d'accord sur le pourquoi elles sont immondes:
Il ne faut pas perdre de vue que le problème de la construction des requêtes de views, c'est que ce sont les modules qui proposent une intégration à views qui sont en partie responsable de la description des tables; et les gens qui le font ont souvent tendance à oublier, que par exemple, la jointure est par défaut en "LEFT" dans views si on ne précise pas "INNER" (mot clé qui ne sert pas à grand chose d'ailleurs) dans la description de ses tables.
Merci cependant pour cet article, c'est très intéressant.
Bien d'accord, cependant aliaser "node" en "node" manque un peu de sel. De plus je ne dis pas que les alias sont mauvais, au contraire, mais que leur longueur excessive semble nuire aux performances de la petite basote mysql. De même pour le "in", je suis bien d'accord que sur Oracle ou PostgreSQL, l'impact est nul, mais ce n'a pas été le cas pour ma base mysql (même s'il reste minime)
Pour les dates, je suis d'accord, c'est tout à fait immonde, mais le support des dates est aléatoire en fonction du SGBD, je comprends que le developpeur ait pu se torturer à ce point pour écrire cette chose immonde, si il veut supporter plusieurs SGBD;
Le support du type "date" est alléatoire, mais l'utilisation du timestamp a quant à lui fait ses preuves, fonctionne sur toutes les bases avec un temps dfe traitement optimum.
Mon vieux prof d'algorythmique m'a toujours dis que l'optimisation est le dernier aspect à aborder pour améliorer la vitesse. En d'autres termes un bon algo non optimisé sera toujours beaucoup plus performant qu'une moulinette viking bardée de caches et d'optimsateurs d'opcode. Pour être un peu moins politiquement correcte, il serait temps que ceux qui se disent développeurs web, recommence à apprendre à développer ;-)
Pour D7, je ne te renjois pas. C'est une couche d'abstraction à la connexion aux bases de données, et aucunement une abstraction de la construction des requêtes elles-mêmes. A ce titre c'est la même chose que JDBC ou ODBC pour PHP.
Pour conclure sur ta conclusion, moi je retraduit cela en "un développeur (web ou pas) ne peut pas faire l'impasse sur une connaissance du schéma de sa base et que du coup Views, la lui masque".
Bonjour,
Un commentaire (Pounard) m'interpelle, plus haut :
Comment ça on est censé s'en passer ? J'ai loupé quelque chose et je dois reprendre mes cours de SQL ? Ou je n'ai pas compris ce que vous souhaitiez dire ?
Tout dépend du schema de données: on voit que CCK créé une seule table qui rassemble tous champs non multiples pour un type de contenu; dans ce cas, si on fait une requête sur un type de contenu particulier, même si les champs sont vides on peut faire un natural join et non un left join, car l'entrée existe quand même en base de donnée (avec des valeurs NULL ou ''). Quand on fait du champ CCK multiple, je vois pas l'utilité de faire un join dans la requête, car on génèrerait des doublons dès lors que plus de deux éléments sont renseignés, faire une seconde requête pour récupérer les éléments au moment de l'affichage serait presque mieux (ce qui se passe de toute manière au node_load() que l'on le veuille ou non, dès lors qu'on affiche en mode node, de manière générale ce que certains modules font dans leur handlers lors de l'affichage).
Je trouve cet article fort instructif ! Cela m'a vraiment donné envie d'essayer cette nouvelle approche en créant son propre module au lieu de passer par l'interface graphique de views pour réaliser ses affichages.
Je pense que ça vaudra le coup pour moi de bûcher encore plus sur l'API de Drupal afin de faire ce genre de chose. Cela sera profitable autant pour mon expérience personnel/professionnel que pour la clareté du code et les gains de performance acquis. :)
Merci beaucoup de nous faire part de ce genre d'alternatives ! :)
Hello à tout le monde et merci pour cet article et pour la somme d'infos qui suit. Une petite question : est-ce que panels pose les mêmes problème que view ? Merci, Timothée
La je ne saurais dire, je n'ai jamais eu l'occasion (et/ou le besoin) d'utiliser Panel. Et la seule fois où je l'ai rencontré sur un projet, son utilisation se résumait à créer des pages qui auraient aussi bien pu être faites par une module custom et un hook_menu...
Salut Yoran,
D'abord merci pour l'article, il est très clair et détaille un problème très intéressant (+ une de ses solutions).
Etant nouveau en Drupal, je comptais utiliser Views pour sa facilité, mais maintenant je préfère tenter le hard coding. En effet, mon site, de part son contenu, aurait nécessité être exclusivement composé de views/panels. Je pense que je lui ferai grand bien en l'allégeant de cette façon.
A ce sujet, j'aurais aimé avoir une mise en page style "grid" ; aurais-tu une idée de comment y arriver ? Peut-être aurais-tu aussi des liens vers une documentation plus détaillée ?
Merci et bon courage,
Ben
Tu entends "grid" au sens css ou views du terme ?
Bonjour Yoran,
Dans ton étude, tu compares la performance de views à la perf d'une requête sql.
Si j'ai bien compris, ta requête sql by-passe views mais aussi le système de hook.
Aurais-tu une idée du gain apporté par le by-pass du système de hook lui-même? (ou de la proportion approximative entre temps consommé par views lui-même et temps consommé par le système de hook)
Hum, pour être certain de comprendre, ta question est elle "est-ce que views utilisé uniquement en générateur SQL, sans mise en forme des données, serait aussi performant qu'une requête simple" ? Si c'est cela je dirais "presque" sans aucun doute. De la bouche même d'une des personnes ayant travaillé sur views, la couche présentation est pour le moins "épaisse" (pour reprendre son terme). Maintenant il s'agit là d'une forme d'utilisation du système hooks. En d'autre termes, ce n'est pas le système de hook qui est en cause plus que l'imbrication, la récurrence et la suite de hooks mis en oeuvre pour créer une vue.
Merci pour l'article. Je me posais la question de savoir quelle était la meilleure méthode pour remplacer toutes mes views par du code custom. Devant déveloper un CRM (et donc bcp de connexions authentifié), Views devenait un casse-tête en terme de performance.
++
Julien (heureusement que la communauté française est là parce que c'est galère de trouver des ressources et de l'aide Drupal sur Hong Kong :)).
PS: Pour info, les commentaires ne marchent pas en mode anonyme. Tu as deux champs commentaires qui apparaissent et du coup, ça bug quelques part.
Je crois que Yoran va poster un de ces 4 le code de son module http://drupal.org/project/datasource
En réalité je me pose la question de savoir si cela intéresse quelqu'un :)
+1 pour datasource :)
AH ? Ben je vais ouvrir mon dépôt GIT alors :) Faut juste que je trouve le module qui va bien (j'en ai vu un traîner dans les dépôts).
merci Yoran !
Je confirme, moi ça m'intéresse énormément.
idem !
j'ai mis une page d'explication sur datasource dans la section "pépinière" avec un accès au code, tout avis est bien évidement le bienvenu.
+2 (mon dév et moi) pour datasource
J'ai lu avec un grand intérêt cet article ainsi que les commentaires.
( Dur dur de s'y retrouver dans la jungle des CMS/Frameworks.
Trop d'open source tue l'open source ;o) )
J'avais l'intention d'investir sur Drupal ( après plus d'une année de cogitations et d'observation du marché ) mais cet article ébranle mes convictions.
A votre avis, Drupal7 a t-il gommé les défauts présentés dans cet article ?
Views est resté Views dans Drupal 7, son UI a été complètement retravaillée mais il fonctionne toujours de la même façon.
Déjà il ne faut pas confondre Drupal et les modules contributions dont fait parti Views. En effet, rien ne t'oblige à utiliser des modules comme Views ou Panels pour ne parler que de mes bêtes noires. Leur incontestabilité sont juste des usages communs en soit totalement contestables. Autant CCK est une extension naturelle des concepts de base de Drupal, expliquant assez bien son intégration dans le coeur de la version 7. Autant l'usage de Views correspond à un choix techniques qu'il convient de valider ou invalider avant de démarrer un projet.
A titre d'exemple, tout les sites que je construis, et qui ne sont pas forcement des plus simples (ex. reforme.net) se passent sans aucun soucis de Views. J'exploite drupal pour ce qu'il est, un framework CMS avec des API très bien faite. Et sur ce point Drupal 7 est sans aucun doute une belle évolution (même si je critique fortement la démarche consistant à casser les API de D6) avec notamment une gestion du requêtage à la base de donnée qui a été dopée aux stéroïdes permettant, entre autre, la fabrication de requêtes dynamique rendant Views encore plus inutile.
En somme, ce que je raconte ici est plus là pour invalider le choix systématique de views et amener les développeurs Drupal à y réfléchir à deux fois avant de s'enfermer dans une solution boiteuse. Après certain évoqueront qu'il faut être développeur pour se passer de Views. Je ne dis pas le contraire et c'est là qu'intervient la taille du projet web visé. Passé une certaine échelle, il me semble de toute façon suicidaire de vouloir construire un site sans savoir développer.
L'autre argument généralement évoqué pour pousser l'usage systématique de views est la maintenabilité. Mais en réalité tout développeur qui a travaillé sur un site utilisant Views à grande échelle, sait que cet argument ne tient pas 10 minutes. Un site d'envergure ce sont plusieurs centaines de listes en tout genre sous différentes formes (blocs, pages, flux, etc.). Un tel contexte transposé dans l'univers "views" c'est des pages et des pages de vues ultra-complexes à modifier dans une interface graphique qui me fait penser au Tardis du Docteur Who ;-). A cela s'ajoute des journées passées à essayer de faire rentrer la demande du client à ce que peut faire Views ce qui se termine dans 99% des cas... à faire du code pour aller étendre son fonctionnement.
Donc, pour conclure, Views n'est pas Drupal et les limitations de views ne le concerne juste pas. Et personnellement je considère qu'au prix où l'on facture un site sous Drupal, la moindre des choses est de fournir un site qui répond à 100% des besoins de nos clients, sans concessions liées à des limitations d'un système pousse-boutons.
Exactement ce que je pense de Views mais parfois, on peut rencontrer des responsables de dev qui te sortent des arguments du genre "As tu déjà essayé de lire du code fait par autrui ? Non parce que quand tu dois manager une équipe de plusieurs développeurs qui travaillent sur plusieurs projets, c'est plus facile d'utiliser Views que de faire ses propres modules en php et utilisant l'API de Drupal"... Là moi, les bras m'en tombent ! C'est la première fois que je rencontre un mec qui me dit que ses développeurs ne savent pas lire du code php...
Pour en revenir à ton gars, c'est d'autant plus étonnant que pour un chef de projet (je l'ai été un paquet d'années), la garantie de la prise en main rapide d'un projet par un nouveau dev, c'est justement l'usage d'un framework qui serait ici celui de drupal. Car autant il est vrai que la reprise d'un projet "hors framework" peut être un véritable enfer, autant un projet "frameworké" limite grandement les délires des artistes ;-)
J'en conclu donc qu'il ne gère pas des développeurs, mais des intégrateurs, ce qui est bien différent.
Je ne vais pas me faire que des copains en disant cela mais, venant du monde industriel, je me suis vite rendu compte que le terme de "développeur" était à prendre avec un peu des pincettes dans le monde web. Dans l'immense majorité des cas les "développeurs" que j'ai rencontré sont des gens très sympas mais qui n'avaient pas la formation et/ou l'expérience du développement tel que moi je l'entendais. D'ailleurs pour eux, HTML et CSS sont... des langages...
Alors il ne s'agit pas évidemment pas d'élitisme mais de précision. Développeur, c'est un métier impliquant la connaissance de plusieurs langages et la capacité, en effet, de lire avec plus de facilité du code, que de comprendre une interface graphique ;-) Et "développer un site" ne consiste donc pas à enquiller des modules, les paramétrer et faire du templating. Ça, dans les métiers de l'informatique, ça a aussi un nom, c'est de l'intégration.
La je suis entièrement d'accord avec toi à propos du fait que beaucoup de développeurs web ne sont pas des développeurs. D'ailleurs dans la monde Drupal c'est un reproche que je suis près à faire ouvertement: énormément de morceaux d'API et de modules contribués ne sont pas prêts pour une utilisation industrielle (du tout). Views, CTools et Panels d'autant plus (ces modules c'est un enfer).
A titre d'exemple beaucoup de développeurs du monde Drupal pensent que plus les noms de leurs fonctions sont courts mieux c'est. C'est en réalité contre productif car ça obfusque la fonction réelle qu'elles ont (une phrase s'écrit sujet-verbe-complet, et j'aimerais autant que leurs noms de fonctions aussi).
Je ne comprends pas cet obsession qu'ils ont à vouloir faire de la magie au lieu de faire du code clair et explicite: plus ils masquent la complexité et paradoxalement plus leur code devient complexe: la seule façon de maîtriser Drupal aujourd'hui c'est de maîtriser son historique depuis la version 5.
Je me permet de citer un article que j'ai lu sur le blog des développeurs Zend récemment (je n'arrive pas à retrouver l'URL), qui parlait précisément des framework web écrits en PHP et de leur évolution récente, qui dans son introduction disait: "Drupal n'est pas un framework bien entendu". Ça m'avait fait rire, et encore maintenant je suis d'accord sur ce point.
C'est clair que malheureusement, je suis tombé dans une équipe d'intégrateurs et non de développeurs. Je partage aussi le même constat et la difficulté à expliquer la différence à des personnes qui ne comprennent pas le métier de développeur.
Et là, je ne vous parle même pas de déploiement qui se fait à coup de features, contexte et spaces...
Surtout, je suis toujours étonné de voir autant d'offres d'emploi où tu vois :
Cherche développeur Drupal maîtrisant Views, Ctools alors que tu devrais voir maîtrisant l'API.
J'espère que la situation est différente en France pour les développeurs sur Drupal parce qu'ici à Hong Kong, je peux les compter sur doigts d'une seule main...
Salut,
j'ai une question qui rejoint un peu votre discussion mais qui pourrait se révéler postée au mauvais endroit [merci de me le signaler].
J'ai dois gérer un affichage de résultats pour un site Drupal sous "MySQL" à partir d'une base de données externe Oracle. Dingue non ?
Bref, je me demandais si je pouvais utiliser views pour taper dans cette base Oracle. Mais j'ai l'impression que views ne sert à mettre en forme que les éléments contenus dans MySQL.
Donc avant de foncer tête baissée, je voulais confirmer qu'il fallait que je développe ces modules moi-mêmes.
Sans doute trivial pour vous, une réponse serait cool. Merci
Hector
Article très sympa, et les commentaires aussi.
En plus d'avoir bien rigolé sur le ton employé, je suis plutôt d'accord avec son Auteur. Tous mes sites et modules se passent de Views. Je m'en suis rendu compte lors d'une session de debugging d'une "vue": étant à 20.000 lieu sous la surface de la stack, je me suis mis à réfléchir... Est-ce vraiment la vision du PHP ? Déjà que les frameworks ne sont pas reconnus pour leurs performances comme le dit lui-même Rasmus Lerdorf, le module Views est vraiment effrayant.
On se croirait dans une stack Java lors du démarrage de tomcat avec une appli web... J'en suis venu à la conclusion que si je devais utiliser un module comme Views, autant faire des EJB en Java. Par contre pour débuter, ce module est top, mais pour tout développement sérieux, je ne compte pas dessus.
Que pensez-vous de l'intégration de Views dans Drupal 8 ? Personnellement je n'y crois pas trop, en plus la version 7.x-3.x introduit une dépendance sur CTools. Donc encore plus de Kilo-LoC à maintenir et à faire tourner a grand coup de hook et de plugins comme tu dis ;)
"Views must die".
Intégrer Views au core n'est pas une bonne idée. Du fait de l'intégration de Symfony, et c'est pas tant pour Symfony lui même mais par l'émergence d'une nouvelle ligne directrice dans le développement du core, ils devraient en profiter pour remettre à plat ce besoin.
Un beau design commence toujours par un beau dessin, et aujourd'hui le développement objet basé sur les interfaces permet d'abstraire l'essence de n'importe quel besoin sans parler implémentation. Views à été construit avec l'extrême inverse des méthodes et est obsolète depuis sa version 1.
Views est un paté immonde et périmé historique de code ignoble en toile d'araignée et mal conçu. Penser à essayer de l'améliorer aujourd'hui pour l'intégrer au core ce n'est que retarder l'échéance du jour où plus personne ne voudra ou pourra maintenir ce projet.
Il est indispensable aujourd'hui d'essayer de développer une véritable API autour de la sélection, filtrage et affichage d'objets, plus abstraite, plus directe et plus simple, et surtout et pas des moindres: plus extensible.
A propos de Symfony, je n'ai pas de recul par rapport à ce framework mais est-ce que cela nécessite une refonte intégrale du code Drupal ? Avez-vous une idée du temps qu'il faut passer pour un débutant sur Symfony pour le maîtriser (juste en Symfony, pas en Drupal et PHP :)) ?
En parlant de Views, quand on supprimera la dépendence de Views pour le module Commerce, ça sera pas mal (suis oubligé de me farcir Views rien qu'à cause de cette dépendance... grrr).
Je pense que Symfony est abordable pour n'importe quel développeur, au moins en tant qu'utilisateur du framework. Après, pour le maîtriser il nécessite d'avoir une bonne connaissance de la programmation orientée objet, mais je ne pense pas que ce soit bloquant. Les paradigmes objet ne sont pas compliqués à comprendre en soit, il nécessitent juste, dans l'absolu, de comprendre une autre façon d'écrire le code, de son côté, l'algorithmique, elle, ne change pas fondamentalement.
Je pense que pour un bon développeur, l'apprentissage du "nouveau Drupal" peut se faire très vite. Il y'a une dimension historique qui ne sera pas évidente à appréhender si on a pas suivit les changement au jour le jour, mais dans l'utilisation même du produit, il n'y pas de problèmes à la condition bien sûr que la documentation suive. Pour un développeur débutant, ça dépendra surtout de ses connaissances du monde objet. Pour un "débutant en Drupal", les parties pures Symfony pourraient s'avérer être les plus faciles à appréhender, car le code historique de Drupal est aussi gros que complexe alors que le code de Symfony est clair et bien découpé.
Pour répondre à ta question, le framework Symfony porte dans son coeur des pans de code complexes et assez difficiles à comprendre. Il faut nuancer cependant, car la documentation officielle est bien construite et assez complète, et un débutant pour s'amuser avec très rapidement, et en comprendre les mécanismes en surface assez rapidement.
Petite note en aparthée, je ne suis pas un grand fan de Symfony, je préfère de loin Zend (et Zend 2 qui arrivera un jour, on croise les doigts). Ceci est une opinion personnelle et je ne veux pas lancer de flamewar sur le sujet.
Drupal 8 dans son état actuel est déjà très différent de Drupal 7, un certain nombre de systèmes sont déjà partiellement ou complètement réécrits, comme on peut le voir avec l'ajout du composant HttpKernel (bootstrap et gestion Request/Response) ainsi que certains autres sous-systèmes moins invasifs.
Commerce souffre de nombreux problèmes de ce côté là, il n'y a pas de Views que j'ai envie de jeter à la poubelle, mais Rules aussi, ainsi que toutes les dépendances en dur à Contextual et autres joyeusetés.
Merci pour la réponse. Faut vraiment que je mette mon nez dedans alors. Bon après, si ça suit la logique object, ça va. Je n'ai pas commencé à regarder Drupal 8 mais j'imagine que du coup, ça forcera au moins le code à être plus standardisé et plus "propre".
Oui ça, je m'en suis bien rendu compte en allant tripatouiller Commerce vu que je dois l'implémenter dans une logique de plateforme pour de multiple websites avec pré-configurations dans une distrib.
Il n'est pas étonnant que drupal commerce ce soit orienté à fond vers rules et views; c'est en réalité un énorme progrès si on considère la version d'ubercart qu'il y avait sur Drupal 6. Celui avait recodé rules (ubercart_conditionnal_actions ou je ne sais plus quoi) en moins bien; et il était très pénible de changer le contenu du caddie. Et views permet de changer en 3 clics les colonnes affichés dans le caddie, ca reste un gros gros gain de temps. (par rapport ubercart encore une fois)
Je prefère le dev aux clickodromes mais Drupal a toujours voulu être un "assembleur rapide de site" (dixit Dries) via une interface d'administration accessible à des non-développeurs. Donc le clickodrome c'est un peu sa nature.
J'ai beau ne pas aimer rules et views en tant que dev, je peux qu'être admiratifs de la puissance que ces outils donnent à des non-développeurs, combinés à la field api et aux tokens.
D'un point de vue intégrateur et pour mettre un site unique à jour, pourquoi pas mais bon quand tu dois déployer ça dans le cadre d'une plateforme basée sur une distro et que tu partages les paramétrages pour l'ensemble de tes sites, accroche toi ! lol. Enfin bon. c'est l'éternel débat. J'attends de voir ce que va donner Conf dans Drupal 8 (enfin si j'ai le temps, faudrait que je contribue un peu aussi :)).
Je rejoins à 300% Pounard sur le principe d'une propre API de sélection de
contenu. Après qu'il y ait un module qui exploite cette API sous la forme d'une
interface graphique et que Merlin s'enorgueillisse de l'intégration de Views
dans le core ne me fera ni chaud ni froid.
Maintenant j'avoue douter que cela prenne une telle direction. Le principe d'API
propre est généralement assez éloigné de la philosophie de conception de
Drupal. Je mets à part tout ce qui touche à la base de données où il y a eu une
sorte d'état de grâce assez rafraichissant. Mais si l'on prend par exemple
FormAPI, toute personne à l'origine saine d'esprit qui a essayé de faire du
form_alter sur node_form D7 a obligatoirement fait un jet de santé
mental dans les minutes qui ont suivies.
Mon sentiment est que le développement de Drupal est marqué par un pilotage à
l'interface graphique. En gros j'ai besoin d'un truc quant je click là, donc je
code la fonction d'API correspondante. Dans un développement classique on a
plutôt tendance à d'abord penser les API, puis ensuite leur implémentation, et
enfin l'interface qui les utilise. Et Views est un exemple assez significatif de
cette approche très particulière du développement informatique. C'est de loin
l'interface graphique le plus hallucinante qu'il m'a été donné de côtoyer et le
code qui va derrière est simplement à son image. Alors intégrer ce truc tel-quel
dans le core de drupal, en y ajoutant en plus des dépendances C-Tools (que j'évite
de juger car je ne l'ai jamais utilisé) j'ai tout de même un gros doute. Maintenant
avec le concept drupalien de la do-ocratie (en gros celui qui a suffisamment de temps
libre pour faire, gagne), ce n'est pas totalement impossible. Maintenant si cela reste
un module que l'on pourra, comme overlay, toolbar et autres drouilles D7, désactiver
d'entrée de jeux, who cares ? Au moins on arrêtera de s'interroger de la non présence de
ce module dans mes projets :-)
Après je n'ai pas suivi l'évolution que prend D8. J'avoue que j'évite de la
suivre car ce que j'en entends me fait vaguement flipper. Aujourd'hui il ne faut pas se
leurrer, migrer un site de moyenne à grosse taille de D6 à D7 revient ni plus ni moins à le refaire
entièrement. Cela peut passer une fois auprès des clients, mais si la même
chose se passe de D7 à D8, ça va complètement décrédibiliser la solution. On ne
peut pas ainsi, sur des délires de geeks, foutre à la poubelle l'investissement
financier de nos clients. Et les sites construits à coup de centaines de
modules n'échappent pas à cette situation, vu qu'une bonne partie des modules en question,
dont la communauté (attention, légende Drupalienne inside) est censé garantir la pérennité d'une version à l'autre
Drupal (ah ah ah), sont soit abandonnées de guerre lasse par leur mainteneur,
soit en béta éternelle, soit remplacés par des concepts fumeux non encore
achevés (ex. L'abandon d'emfield au profite de Media). Résultat des courses,
le site construit par un builder est finalement bien moins facilement migrable
qu'un site construit par un développeur, cherchez l'erreur... Et j'en connais
beaucoup qui érent ainsi dans les limbes en cherchant désespérément leur
"upgrade path" vers D7...
Le résultat chiffré de ceci se voit assez clairement les statistiques (bien cachées, notez) du projet Drupal :
http://drupal.org/project/usage/drupal
On y note que l'arrivée de D6 a bien fait baisser les sites en D5. En revanche
l'arrivée de D7, n'a que peu infléchit la courbe des sites D6. Résultat, comme
pour Android, grosse fragmentation en vue. D7 a clairement apporté de
l'audience à Drupal, mais n'a tout aussi clairement pas entrainé une migration
massive, en pour cause, c'est souvent impossible.
Bref, je ne suis pas vraiment rassuré sur l'avenir et aujourd'hui j'explique
clairement à mes clients qu'un projet fait avec une version de Drupal, restera
sur cette version pour tout son cycle de vie.
Sinon merci les gars, vous m'avez convaincu de ne pas utiliser Drupal
Commercie, ajouté à ma blackliste avec Views, Context et Features. J'y ai
rajouté récemment Apache Solr Search (pas Apache SOlr tout court) qui
maintenant dépend d'un Facet API qui dépend de CTools (je rêve...) et
field_group pour les mêmes raisons. Pour Rules, il marchait pas si mal en D6,
mais en D7 il me plante mes sites direct... J'ai donc redécouvert
Action/Trigger qui finalement faut le job.
Merci pour ce commentaire, je vois que nos avis se rejoignent sur beaucoup de choses! Attends de voir Migrate et Search API, deux modules qui ont le méritent de partir d'un design de base très bon, mais d'une implémentation objet qui n'a d'objet que le mot-clé "class". Code en toile araignée, illisible, pas ou peu d'interfaces, abstractions aux mauvais endroits, ce qui génère une impossibilité de l'étendre simplement et efficacement, et vocabulaire généraliste spécifique à l'informatique non maîtrisé (on peut pas demander à tous les développeur d'avoir une culture, mais utiliser le nom d'un design pattern connu quand on l'utilise, même sans faire exprès, c'est tout de même mieux).
J'ai arrêté d'utiliser "Services" lorsqu'ils ont introduit la dépendance à CTools... Idem pour Média, un module qui en met plein la vue sur le papier: écrit par la team d'ingénieurs Acquia, se voulant unifier les API, etc. mais ne tiens pas toutes ses promesses.
Dans mon détecteur de projet foireux, il y a un bon indicatif, dès qu'il y a une dépendance sur CTools, cela démontre la paresse des développeurs, et donc que forcement cela va se déteindre sur la qualité de la conception. Simple is hard !
Déjà, dans mes cours de génie logiciel (objet et composant) nos professeurs nous avertissaient: dès qu'il y a un paquet nommé "utils", ou "tools" dans le software, c'est que la conception est mal faite. La découpe en composants à été baclé, et le paquet en question se retrouve à contenir des classes univers ou chaque développeur ajoute sa modification au fil de l'eau au lieu de faire un peu de refactoring. Alors de là à carrément créer un module "tools" c'est un peu la parodie de la mal-conception!
Copain \o/
J'évite aussi CTools autant se faire que peut. C'est aussi offusqué qu'inutile, de plus il jouit de quelques bugs dans la gestion des cache qui ont tendance à déclencher des requêtes en écriture sur toutes les pages.
À fuir de toute urgence.
J'ai écris un poste sur les dangers de Views in core.
C'est accessible ici: groups.drupal.org/node/249068.
Dis donc ça discute sévère sur ton post mdr !!! Non mais laisse tomber la discussion. Tu vois bien que les mecs qui te répondent n'ont pas la culture ni même la curiosité de comprendre la "beauté" d'une abstraction d'une application ni même le concept d'un "framework". Ils ne voient le problème que par le biais de la fonctionnalité. Et "j'adore" le côté, "C'est super populaire et c'est utilisé sur plein de site donc ça doit forcément être dans le core et ça veut dire forcément qu'on ne peut pas s'en passer !". Ah ah ah. Y a pas un peu de feinéantise d'esprit dans le coin ?
Le jour où Drupal sera un conglomérat d'API (Permission, Field, User, Content (ou Entity suivant le nom actuel...)) avec des modules optionnels qui proposent des UI pour ceux et celles qui veulent s'en servir, là on pourra espérer ne plus avoir ce type d'échanges. Du genre, Data API et Data UI. De plus, ça permettrait de supprimer des fonctionnalités et des modules qui n'ont rien à faire dans le core (du genre forum et node qui traîne tjr dans le coin !!!). Ça permettrait d'espérer un Conf API qui serait fort utile.
C'est là où on voit vraiment deux mondes. Celui des intégrateurs qui ne pensent à la fonctionnalité finale et les développeurs qui veulent utiliser un bel outil.
On peut espérer que 'adoption d'un framework comment Symfony permettrait d'imaginer Drupal Core comme un ensemble d'API qui fonctionnerait au dessus de Symfony.
Allez courage les gars ! On ne doit pas être les seuls à penser ça ah ah ah :).
ndlr: signé Julien, de Hong Kong ;-)
Oui, certaines personnes sont trop ignorantes pour changer malheureusement.
Heureusement il y a des personnes de confiance dans la team de dev
core:Crell, sun, catch qui sont très talentueux et me fait garder
espoir en Drupal :)
Sylvain
Hello pounard, toujours les mêmes dans les parages à ce que je vois :)
En effet :) Je viens peu sur ce blog, mais je suis toujours les commentaires qui passent!
Dans les parages, ça fait un gap entre Paris et Hong Kong (enfin je suis peut-être le seul qui soit sur HK :).
D'accord avec Pounard, Views dans le Core c'est pas une bonne idée, d'ailleurs views tout cours c'est pas une bonne idée, même si ca dépanne
A vouloir tous faire (Query Builder, Data Formatter) ca fait la grosse usine à gaz qui deviens rapidement ingérable, surtout quand on connait les problèmes de staging de Drupal
Une belle API type ORM pour construire sa requête, piper cela dans un data formatter c'est à mon avis solution plus solide.
Vive les Interfaces, je comprends pas encore tout aux API de D8, mais ca m'a l'air prometteur
Hello à tous et particulièrement à Sylvain,
Hé oui, les parages sont assez courts en fait, car je suis le benoit que tu contactes de temps en temps à ton boulot :)
@+
Publier un nouveau commentaire