Si l’homme a bien compris une chose, c’est qu’il est inutile de réinventer la roue tous les jours.
Par souci d’économie, de temps mais surtout parce que c’est complètement absurde…
Dans cette optique, sont apparus les frameworks et CMS qui proposent tous le meilleur comme le pire.
Si les frameworks sont un besoin et un réel atout dans les phases de conception modernes, l’utilisation de CMS doit se faire dans un cadre bien défini et non à outrance…
Il existe des dizaines de CMS (surtout en PHP). Certains brillent par leur simplicité, d’autres par leur ouverture.
Au milieu se trouvent ceux que l’on utilise beaucoup mais qui ne sont ni simples ni bien développés… Drupal en est la représentation parfaite…
187976 tables…
Au moins…
On a beau avoir vu des quantités de projets de grande envergure, avec des masses de données importantes, il est rare de voir autant de tables pour si peu…
Et la bonne blague ; c’est que les modules externes rajoutent des tables, la création de types de contenu rajoute des tables, etc.
Le tout centralisé dans une seule et unique table de liaison : node…
En InnoDB, c’est clairement l’éclate !
Un approche tordue…
Nous sommes en 2011 (ça nous rajeunit pas, hein ?!) ; difficile de passer à côté de la POO dès lors que l’on trempe ses mains dans le développement.
Tout s’axe autour des motifs de conception, des implémentations, des héritages et de tout ce qui se rapproche de près ou de loin de la notion d’objet.
Visiblement, et malheureusement, ce n’est pas le cas de Drupal.
On est dans une logique complètement procédurale qui pousse même le vice jusqu’à utiliser des méthodes dépréciées voire dangereuses entre les mains d’un enfant…
Vive la RAM !
Pour faire tourner le tout, pensez à vous équiper d’une machine blindée en RAM et avec 42 processeurs de 2048 cœurs chacun…
Montez la mémoire allouée à PHP à 20Go, la mémoire allouée à MySQL à 10Go et priez pour ne pas avoir deux internautes connectés en même temps sur le site.
Drupal est clairement un bouffeur de ressources.
Ce qui paraît plutôt étrange quand on désire juste afficher une simple page de contenu…
Au final…
Un CMS doit être utilisé dans un cadre bien défini en respectant le rôle que lui ont imaginé ses développeurs.
Pour faire plus (ou mieux), préférez un vrai framework tel que le Zend Framework ou Symfony et concevez vous-même votre base de données.
Drupal ne mérite pas le rang qu’on lui attribue et profite très certainement d’un effet de mode.
Sa forte présence sur le marché résulte simplement de choix réalisés sans prise de conscience de l’absurdité de sa conception…
C’est d’autant plus dommage que ce genre de projet contribue à dévaluer un langage comme PHP qui, bien utilisé, s’avère extrêmement puissant.
Maintenant, allez faire comprendre ça à quelqu’un qui n’a jamais mis le nez dans du code…
Même si je suis assez d’accord, ton post n’est pas assez détaillé je trouve. D’où sort ce chiffre de 187976 tables? Quelle méthodes sont dépréciées? Drupal fait partie du projet GoPHP5, cela devrait arranger les choses non?
Pour le nombre de tables, on va mettre ça sur mon côté toulousain. Faut en enlever un peu… 😉
Je sais pas si tu as lancé un Drupal en PHP5.3, tu te prends des DEPRECATED sur toutes les pages.
Enfin, je ne suis pas sûr que le GoPHP5 sauve la mise, il y a un problème de conception plus profond selon moi…
Axel, tu veux un équarissage en règle, et détaillé, de Drupal ?
tu vas être servi :
Pourquoi je déteste Drupal (et la plupart des autres CMS) => http://www.freeblogware.org/2010/06/pourquoi-je-deteste-drupal-et-la.html
J’ai jamais voulu utiliser de CMS, je n’aime pas le principe d’installer 30 tables pour un site vide. Je pensais que le GoPHP5 allait arranger le code, mais si tu dis que non, …
@Gauthier, merci je vais lire ton post.
Ça dépend, pour ce blog et ce que j’en fais, j’aurais perdu du temps si je n’avais pas utilisé un CMS.
Il faut bien cadrer le besoin en fait.
Tu es developpeur de sites vides toi?
@Gauthier: ok c’est clair, ca rejoint ce que je pensais. Vive Kohana!! Framework PHP5 objet, surchargeable, j’adore…
@Aurélien: ouais, pour un blog, bien sûr. Mais dans le cadre d’un projet pro, finalement tu ne perds pas tellement de temps à tout redévelopper avec un framework que tu connais par coeur, pour lequel tu as déjà tes classes toutes prêtes et réutilisables.
C’est vrai qu’une seule table SQL, ou on met tout dans un gros array sérialisé, c’est mieux.
ouhla ça ça ressemble comme deux gouttes de drupal au commentaire de quelqu’un qui gagne sa vie en tant que « développeur drupal » et qui se sent piquer au vif.
une fois pour toutes, il faut se mettre dans la tête que les CMS ne servent qu’à gérer du contenu. Rien d’autre. Et qu’ils n’ont vocation à être utilisé que si et seulement si on a pas les moyens de faire autrement.
C’est une solution par défaut, quand on a pas le budget et/ou la compétence de créer l’outil dont on a vraiment besoin.
Utiliser Drupal, c’est manger des raviolis en boite…
Intéressant comme technique de développement, écris un post sur ta technique, cela intéressera surement quelques personnes
@Axel pour ce sujet précis j’ai déjà posté le lien : http://www.freeblogware.org/2010/06/pourquoi-je-deteste-drupal-et-la.html
Sinon, trouve des archives de Programmez, ça fait dix ans que j’écris des articles sur le développement PHP dedans 🙂
Ca te donnera l’occasion de constater d’ailleurs que j’ai énormément évoluer dans ma façon d’appréhender le développement avec PHP – ce qui ne me semble pas être le cas de la plupart des communautés fédérées autour de projets de CMS…
@Gauthier:
Tu as tout a fait raison. Un CMS, ca gère du contenu, et pour le reste, c’est un framework. Chaque outil à son role.
Juste ca me fait marrer de vous voir s’indigner devant des tables créées par défaut 🙂
@Gauthier: mon message précédent s’adressait à Mister N. 😉
@N je ne m’indigne bien entendu pas du fait que des tables soient créées par défaut
ce qui me pose problème c’est leur nombre excessif, et leur conception générale, qui amène a des requêtes lourdes, très nombreuses, avec beaucoup trop de jointures…
ce qui m’indigne en revanche, c’est que le module CCK si je me souviens bien, qui créé des colonnes à la volée quand on ajoute un champ personnalisé, se mêle ensuite parfois de détruire ces colonnes pour les reporter des des tables qu’il créé elles-aussi à la volée, t’interdisant de ce fait d’écrire des requêtes SQL pour suppléer à une lacune d’un module.
Rise of the machines…
Salut ancien collègue,
Drupal est très demandé auprès des SSII mais mon collègue au travail a laissé une très mauvaise impression en utilisant Drupal (au lieu de Typo3)
J’ai beau être un dev POO farouche, je refuse de démonter Drupal pour son coté procédural.
Je ne suis pas le seul à estimer que le procédural est aussi bon que de la POO dont les orientations et traces sont clairement obscures dans certains cas (beaucoup de cas en fait – e.g. tente de débuger un webservice une fois, pour le fun)
La gestion des tables de Drupal est pas très bonne mais a le mérite de permettre du requêtage complexe… ce qui n’est pas forcément le cas partout (je pense à ez Publish par exemple…)
Drupal est un CMS, pas un Framework, l’amalgame est vite fait dans ton post et je suis presque « choqué » de lire ce que tu écris… mais je respecte le fait que tu ne l’aime pas.
De là à dire qu’il détruit l’aptitude du langage je ne suis pas d’accords.
Pour information, R.Lersdorf n’aime pas non plus la POO… ça fait pas de lui un mauvais codeur
Je ne vais pas paraphraser ce que j’avais écrit plus haut pour te répondre.
Je maintiens toujours mes propos.
Par ailleurs, je ne vois pas la difficulté dans le fait de débugguer un WS ni le rapport avec la POO…
Et je parle en (très) grande connaissance de cause.
Certains diraient : « les tests unitaires sont là pour ça ».
En ce qui concerne Rasmus, je pense juste que comme tous les créateurs, il n’aime pas qu’on utilise son œuvre d’une manière différente que celle qu’il avait imaginée…
Salut Metald3d,
pardonne par avance mon ton… taquin
> Je ne suis pas le seul à estimer que le procédural est aussi bon que de la POO
tu n’es sans doute pas seul, mais par bonheur tu appartiens à une espèce en voie de disparition 🙂
> La gestion des tables de Drupal est pas très bonne
euphémisme…
> mais a le mérite de permettre du requête complexe
faux – la gestion des tables de Drupal oblige à passer par ses API pour requête, car il modifie dynamiquement la structure même de la DB. Donc si tu écris une requête en dur, elle peut péter à tout moment.
> Drupal est un CMS, pas un Framework
Je crois ne pas dire d’ânerie si je rappelle que c’est Drupal qui se revendique être un « CMF » (content management framework)
> Pour information, R.Lersdorf n’aime pas non plus la POO… ça fait pas de lui un mauvais codeur
Rasmus est à mon avis un aigri, et un gros provocateur. En outre, je ne sais pas depuis combien de temps il n’a pas écrit une ligne de code, mais si ça remonte à PHP/FI tout s’explique 🙂