Views, Panel... et les projets web "importants"

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by Droul on

Bonjour,

Je suis actuellement en train de construire un site sous Drupal, et m'interroge sur l'utilisation de Views, surtout, et accessoirement Panels.

En effet parfois je lis que ces modules peuvent plomber un projet, car ils sont lourds et usent beaucoup de ressource (entre autres), et parfois qu'ils sont indispensables, et qu'ils représentent l'avenir, notamment pour Views, puisque ce dernier va être intégré dans le coeur de drupal 8.

Qu'en pensez-vous ?
Est-ce que dans le cadre d'un projet assez "important" (fort trafic espéré etc.) il est convenable d'utiliser views et panels ? Ou est-ce qu'il vaut mieux essayer de s'en passer ?

Merci d'avance de vos réponses ;)

Forum : 
Support général

Soumis par vincent59 le 17 Octobre, 2012 - 16:43

La réflexion doit même se faire un peu en amont : faut-il ajouter une multitude de champs sur un contenu simple, ou créer une entité, proche d'un modèle de données relationnel ?

Si le contenu est très spécifique, il vaut mieux passer par des entités, qui vont permettre de limiter les accès à la base de données.

Si le contenu est assez simple (peu de champs ajoutés), View peut gérer des caches de pages, et donc avoir un impact relatif sur les performances. Couplé avec un opcode cache (APC) et autres, ça peut aller.

Il est possible de démarrer avec Views, de voir les requêtes exécutées (avec le module Devel). Si c'est vraiment trop moche, faire un module qui utilise des requêtes optimisées

Soumis par Numerizen le 17 Octobre, 2012 - 18:40

Tout à fait d'accord avec cette approche, tenant compte du fait qu'on peut vraiment aller très, très loin avec Views, et se pourrir beaucoup, beaucoup la vie en s'en passant.

C'est une grosse qualité de Drupal : on peut utiliser du tout venant qui est souvent déjà très bien, et le bypasser quand les choses se compliquent.

Soumis par Droul le 20 Octobre, 2012 - 10:13

Merci pour vos réponses, j'y vois plus clair.

Mais donc, comment peut-on créer une entité ? Car actuellement, si je ne dis pas bêtise, on peut seulement créer des types de contenu simples et y ajouter des champs (?).

Et donc si on crée une entité, plus de views c'est bien ça ? Donc plus de listes et de filtres exposés "faciles" à mettre en place ?

Si je m'interroge sur views, c'est aussi parce que dans mon projet, je dois impérativement passer par la création d'un module (aucun module n'existe pour ce que je veux faire)(qui pourrait fonctionner en complément de views, ou non, et si non il devra recréer certaines des fonctionnalités de views). Donc je me demande si il ne vaut mieux pas dès le début tout mettre à zéro et ne pas passer par views, plutôt que d'y revenir plus tard et devoir recréer toutes les vues par exemple.

Aussi, si je crée un module qui fonctionne avec views, views étant ensuite mis à jour etc. je devrai modifier mon module pour qu'il fonctionne avec les nouvelles versions de views, j'imagine?

Soumis par vincent59 le 20 Octobre, 2012 - 21:24

Effectivement, pour créer des entités actuellement il faut passer par du code et un module spécifique.

Par contre, cela n'empêche pas l'utilisation de Views. Il faut savoir que depuis Drupal 7, les nodes, users, etc. sont des entités.

Du coup tu combines les 2 avantages : une seule table avec tous tes attributs (que tu peux aussi compléter par des champs), et l'utilisation de Views, Entity Reference, etc.

Par contre, comme tu le dis, si tu démarres actuellement avec des "nodes" et que tu passes ensuite sur tes propres entités, il faudra refaire les views.

Quelques liens qui m'ont bien aidé :
http://www.trellon.com/content/blog/creating-own-entities-entity-api
http://www.istos.it/blog/drupal-entities/drupal-entities-part-3-programm...
http://blog.haza.fr/entite-cekouaca

Soumis par Droul le 21 Octobre, 2012 - 20:43

Merci pour ces éclaircissements vincent.

Une dernière question, j'ai du mal à m'y retrouver dans les mises à jour et savoir quoi faire.

Un module réalisé aujourd'hui, ne sera plus d'actualité sous Drupal 8, qui sortira en août je crois... Est-ce que cela pose problème ? Je devrai donc rester sous Drupal 7, si je ne veux pas avoir à mettre à jour le module ? Quid des éventuelles failles de sécurité ou autres ?

Soumis par vincent59 le 22 Octobre, 2012 - 08:24

La date présumée de sortie de Drupal 8 est août 2013, effectivement. Ce qui veut dire que Drupal 7 est encore supporté (mises à jour du "core") jusque la sortie de Drupal 9 (environ 3 ans).

Tout cela laissera un peu de temps aux différents modules que tu peux utiliser pour être portés sur Drupal 8. Pour le module que tu réaliserais, il faudra voir si les API ont changé entre Drupal 7 et 8, et estimer les impacts.

Soumis par Numerizen le 22 Octobre, 2012 - 09:21

Il est à peu près certain qu'il n'y aura pas de compatibilité ascendante D7 -> D8, mais effectivement cela ne deviendra vraiment un problème que dans 3 ans au pire. C'est inférieur à la durée de vie raisonnable d'un site avec la même codebase, donc je ne crois pas non plus que ce soit un paramètre à prendre en compte.