Pourquoi drupal crée des adresses en ?q=blabla/blabla/ au lieu des &blabla=xx&string=xx habituels?

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 nyl auster on

Bonjour !
tout est dans le titre; je me demande depuis le départ la raison de l'utilisation d'une unique variable q dans l'url de Drupal plutôt qu'une utilisation classique avec

"mavariable=12&monchat=miaou&etc=..."

Si quelqu'un peut apporter ses lumières à un apprenti Jedi...

Forum : 
Développement

Soumis par nyl auster le 2 Juillet, 2009 - 17:41

Tu as fait beaucoup de boulot là dessus mais il existe surement un module de FAQ sur drupal 6 qui permettrait d'organiser ça tout beau tout propre. Tu ne peux pas te proposer à l'équipe pour te charger de la partie FAQ ?

Soumis par Yoran le 2 Juillet, 2009 - 17:29

Ca c'est une question bien tricky :)

D'abord ce n'est pas tout à fait vrai. Regarde le pager par exemple, lorsque tu cliques sur la page 10, tu as bien (si tu n'es pas en URL simplifiée) un ?q=node&page=10. Les modules peuvent donc utiliser les variables qu'ils veulent.

Ensuite il faut comprendre comment ça marche en interne. Une URL Drupal n'a qu'un objectif, déclencher l'exécution d'une fonction PHP. Le "return" de cette fonction sera le $content de la page.

Pour que cela marche, il faut bien que Drupal sache laquelle appeler. Donc d'une manière ou d'une autre il devait y avoir un nom de variable fixé pour contenu le "nom" de la fonction à appeler. Le choix aurait put être ?function=ma_fonction. Ici le choix a été ?q=ma_fonction, avec q pour query.

Maintenant cela serait un peu casse-gueule de directement fournir le nom d'une fonction PHP à exécuter. Donc l'idée a été de dire que la variable q contiendrait un chemin. Et que chaque module qui voudrait déclarer une fonction, l'associerait à un chemin unique (utiliser un chemin plutôt qu'un identifiant est pratique pour créer des hiérarchies). C'est le rôle du fameux hook_menu qui fournit, par module, un tableau qui associe un chemin (et donc une valeur de q) à une fonction (la callback). A titre d'exemple, le module "node" associe le chemin "node" à la fonction "node_page_default", qui est la page d'accueil de base de Drupal.

Ceci étant fait, on a aussi envie de passer des paramètres à cette fonction. Là aussi on aurait pu formaliser cela sous la forme ?q=chemin/vers/fonction&parametres=p1,p2,p3. Mais il est plus élégant d'intégrer ces paramètres dans le chemin en lui-même ?q=chemin/vers/fonction/p1/p2/p3. Dans le hook_menu, le module va donc déclarer dans son chemin unique, des éléments "variables" qui seront les paramètres de a callback.

Pour reprendre l'exemple du module "node", il va déclarer le chemin node/%node/edit (note le % pour "élément variable") et l'associer à la fonction node_page_edit($node). C'est d'ailleurs là dessus que Dries a fait un énorme boulot entre Drupal 5 et 6.

En fait l'erreur classique est de croire que, comme pour une application PHP classique, l'URL induit la page. En fait le processus de Drupal est un peu différent :
1/ Il démarre (bootstrap)
2/ Il cherche la callback (appelé aussi "menu handler") pour le chemin _GET['q']
3/ S'il n'y a pas de callback => 404
4/ S'il la personne n'a pas les droits sur la callback => 403
5/ Il exécute la callback en lui filant ses paramètres et on stocke son content dans un $content
6/ Il exécute la fonction theme('page', $content) qui va "skiner" le retour de la fonction avec le thème
7/ Il fait un "print" du résultat.

Note: Du coup, tu peux utiliser les callbacks à ta convenance. Par exemple si tu ne veux pas utiliser quicktab pour mettre deux pages dans deux onglets, tu peux faire un module avec un chemin associé à une callback qui renvoie le code XHTML de deux onglets et pour chaque onglets, tu vas rechercher la callback de tes deux pages respectives, les exécuter et y coller le résultat. Tu peux faire ainsi un "pas-quick-tab" en 10 lignes de code :)

Donc tu l'auras compris, on n'utilise pas les variables "classiques" en Drupal car ce n'est pas nécessaire; ni élégant, pour le but de base qui est d'associer un chemin éventuellement à éléments variables à une fonction avec éventuellement des paramètres.

Pffff je sais pas si c'est clair mon truc mais c'est pas si simple à expliquer :)

Soumis par nyl auster le 2 Juillet, 2009 - 17:34

Ouah quel exposé !
oui j'avais vu pour le pager mais c'est un peu l'exception qui confirme la règle.

Si c'est très clair merci. En gros si je saisis bien on est arrivé à ce systeme via le mappage url/callback puis par élégance (?) on a fait suivre les arguments des fonctions à la suite avec des slash.

C'est très perturbant au début le dispatching automatique des arguments parce que ça oblige à un ordre préétabli (impossible de retrouver une variable avec son nom ! ) et qu'il faut se torturer un peu les méninges sur les hooks menu pour pas se mélanger les pinceaux entre
- la partie de l'url qui est l'identifiant (path) de la fonction mais en plus de ça inclut une hiérarchie d'autorisation et de callback
- la partie de l'url qu'on récupère en tant qu'argument.

Comme tout ça me paraissait très obscur (et brillant à la fois, drupal quoi); je me demandais comment on était arrivé à ce systeme.

"il va déclarer le chemin node/%node/edit et l'associer à la fonction node_page_edit($node). C'est d'ailleurs là dessus que Dries a fait un énorme boulot entre Drupal 5 et 6."

je n'ai pas encore fait le passage à la D6 (niveau framework) mais j'ai hâte de tester ça. Merci dpour cette réponse détaillée.

Soumis par Yoran le 2 Juillet, 2009 - 17:51

En fait j'ai oublié l'argument principale de ce système de menu. C'est ce que l'on appelle le pattern MVC (Model Vue Controler). Le principe est que Drupal joue le rôle de contrôleur entre la demande (requête) et l'action (callback). La callback quant à elle est la seule qui connaît le "mode". Et d'une certaine manière, le theming joue le rôle de "vue" sur ce que renvoie la callback.

C'est aussi cela qui fait la robustesse de ce système. Et pour relier ceci à ta question d'origine, comment assurer un contrôle parfait sur les demande (droits, intégrité, etc) si on laisse à chaque fonction la liberté d'utiliser les variables qui lui chantent. C'est aussi pour cela que le coup du pager reste une exception qui tient plus au fait que son utilisation est transversale à potentiellement toutes les callback (toute peuvent en effet déclarer un pager).

Ceci étant dit, une bonne manière de ne pas te mélanger les pattes est d'imaginer chaque élément du chemin comme un dossier. C'est pour cela que je parle d'élégance, c'est une vision empruntée au protocole REST (cf wikipedia). Le chemin est une ressource ou une action qui peut être envisagée comme une arborescence de répertoires ou encore de namespaces.

En tout cas content que mon explication ait été compréhensible.

Soumis par nyl auster le 2 Juillet, 2009 - 18:46

Tu me donnes du grain à moudre, je vais me renseigner sur tout ça (MCV, REST).

"Je crois juste que je vais éviter à l'avenir de perdre mon temps...:("

Tu as essayé de contacter l'équipe et tu n'as pas eu de réponse?

Soumis par remedact le 2 Juillet, 2009 - 18:40

salut,

ben je viens de remettre un message,
mais des fois, j'ai l'impression qu'il n'y a personne dans le bateau...
Je veux dire par là que Drupalfr stagne et c'est bien dommage...
On ne sais pas qui est l'équipe, elle ne répond pas etc...

Bah, je crois juste que je vais éviter à l'avenir de perdre mon temps...
:(