Le hook 'actionDispatcher'

[Erikku]

Quelqu'un sait-il ce que fait ce hook (actionDispatcher) dans Dispatcher.php?

Je n'en ai trouvé aucune autre trace.

// Execute hook dispatcher
if (isset($params_hook_action_dispatcher))
Hook::exec('actionDispatcher', $params_hook_action_dispatcher);

[Erikku]

Ces deux lignes se servent a rien, un peu de nettoyage va etre necessaire.

[olea]

Comment ca elles ne servent à rien ?

 

Elles sont là si un module a besoin de se greffer sur ce hook.

[Broceliande]

Comment ca elles ne servent à rien ?

 

Elles sont là si un module a besoin de se greffer sur ce hook.

 

+1 ...

[Erikku]

Comment ca elles ne servent à rien ?

 

Elles sont là si un module a besoin de se greffer sur ce hook.

Ce hook n'existe pas.

Une autre suggestion?

 

+1 ...

Ca veut dire quoi +1?

[Broceliande]

Effectivement le hook n'est pas dans la table des hooks.

Ceci dit il est plus facile de l'ajouter depuis un module que de faire une surcharge pour que le hook soit appelé.

 

+1 veut simplement dire "je partage l'avis de celui que je cite..." en gros on se joint à l'avis donné sans en rajouter...

On appelle ça plussoyer

[J. Danse]

Aucun hook n'existe pas. (Du moins, en 1.5).

 

Ce n'est pas parce qu'il n'est pas en DB qu'il est inutilisable ou non existant. D'autant plus si il est dans le code même.

[Eolia]

Aucun hook n'existe pas. (Du moins, en 1.5).

 

Ce n'est pas parce qu'il n'est pas en DB qu'il est inutilisable ou non existant. D'autant plus si il est dans le code même.

 

+2!

[Broceliande]

Aucun hook n'existe pas. (Du moins, en 1.5).

 

Ce n'est pas parce qu'il n'est pas en DB qu'il est inutilisable ou non existant. D'autant plus si il est dans le code même.

 

Je plussoie également, en même temps avec le recul, s'il n'est pas dans la bdd ça représente bien un loupé/oubli (?), ce que soulignait notre ami Erikku.

Ici on a beau jouer sur l'aspect technique, il est clair que ce hook n'est pas pleinement intégré...

 

Le pourquoi du comment risque de rester un mystère, mais on peut peut être rendre à ce topic ce qu'il mérite en cherchant ce que nous pourrions bien faire de ce hook ?

[J. Danse]

Je ne suis pas d'accord.

 

Logiquement, un module est censé enregistré le hook auquel il fait référence lors de son installation.

 

Bien évidemment, il faut trifouiller le code pour connaitre l'existence de ce hook, mais n'oublions pas non plus qu'il faut aller en BDD le cas échéant pour le voir.

 

Il existe une multitude de hook non inscrit en BDD. Ce sont les dynamiques.

 

De plus, si un module doit l'utiliser, il sera enregistré automatiquement.

 

Maintenant, oui, il faut chercher quel module pourrait éventuellement l'utiliser

[olea]

Je plussoie également, en même temps avec le recul, s'il n'est pas dans la bdd ça représente bien un loupé/oubli (?), ce que soulignait notre ami Erikku.

Ici on a beau jouer sur l'aspect technique, il est clair que ce hook n'est pas pleinement intégré...

 

Le pourquoi du comment risque de rester un mystère, mais on peut peut être rendre à ce topic ce qu'il mérite en cherchant ce que nous pourrions bien faire de ce hook ?

Je plussoie...

Erikku, ton premier post n'est pas très clair, mais efectivement, il n'est pas logique que dans le code on trouve un appel à un hook qui n'est pas en BDD.

 

A mon avis, il était peut-être prévu dans les toutes première versions de la 1.5 et qu'ensuite, avec les hooks dynamiques, ils ont décidé qu'il n'avait pas besoin d'être explicite

[Erikku]

En gros, vous me dites tous que ca sert a quelque chose mais vous ne savez pas a quoi..

 

+1 veut simplement dire "je partage l'avis de celui que je cite..." en gros on se joint à l'avis donné sans en rajouter...

On appelle ça plussoyer

Je me coucherai moins bete ce soir.

 

Aucun hook n'existe pas. (Du moins, en 1.5).

Ce n'est pas parce qu'il n'est pas en DB qu'il est inutilisable ou non existant. D'autant plus si il est dans le code même.

Ca veut dire quoi "Aucun hook n'existe pas."?

Comme je disais dans mon premier post, "Je n'en ai trouvé aucune autre trace.", ni dans le code, ni dans la DB j'aurais pu préciser.

 

Bien évidemment, il faut trifouiller le code pour connaitre l'existence de ce hook, mais n'oublions pas non plus qu'il faut aller en BDD le cas échéant pour le voir.

[..]

Maintenant, oui, il faut chercher quel module pourrait éventuellement l'utiliser

Meme commentaire que ci-dessus.

 

Il existe une multitude de hook non inscrit en BDD. Ce sont les dynamiques.

Je n'ai pas encore lu tout le code, tu peux donner quelques exemples que j'aille voir?

Si tu penses que ca peut interesser du monde, tu peux meme ouvrir un autre topic pour en parler.

 

Erikku, ton premier post n'est pas très clair, mais efectivement, il n'est pas logique que dans le code on trouve un appel à un hook qui n'est pas en BDD.

Qu'est ce qui n'est pas clair?

 

Hook::exec('actionDispatcher', $params_hook_action_dispatcher);

Comme le hook n'existe pas dans la DB, cela retourne systematiquement une string vide. Et de toute facon la valeur retournée n'est pas assignée, donc elle est perdue. Et il ne semble pas que ca fasse autre chose d'utile.

 

Ca m'a tout l'air d'etre du vieux code. Un petit commentaire n'aurait pas fait pas de mal.

 

Donc a moins que quelqu'un n'ait quelque chose de concret, ces lignes peuvent etre nettoyées, et avec, toutes les lignes qui set $params_hook_action_dispatcher.

[J. Danse]

Ca veut dire quoi "Aucun hook n'existe pas."?

Comme je disais dans mon premier post, "Je n'en ai trouvé aucune autre trace.", ni dans le code, ni dans la DB j'aurais pu préciser.

 

Ça veut seulement dire qu'un hook est disponible du moment où on l'enregistre. En réalité, l'enregistrement en DB permet plusieurs choses, notamment la performance et pouvoir gérer les positions facilement mais du moment ou un module enregistre un hook, si celui-ci n'existe pas, il est automatiquement enregistré.

 

Concernant le code, tu en cites toi-même:

Hook::exec('actionDispatcher', $params_hook_action_dispatcher);

 

C'est donc qu'il en existe une trace !

 

Je n'ai pas encore lu tout le code, tu peux donner quelques exemples que j'aille voir?

Si tu penses que ca peut interesser du monde, tu peux meme ouvrir un autre topic pour en parler.

 

Les hooks dynamiques sont ceux d'ajout et d'uptate d'objets. Pour de plus amples précisions, je te conseille la lecture de mon article (disponible sur ce post)

 

 

Comme le hook n'existe pas dans la DB, cela retourne systematiquement une string vide. Et de toute facon la valeur retournée n'est pas assignée, donc elle est perdue. Et il ne semble pas que ca fasse autre chose d'utile.

 

La méthode exec() de la classe Hook exécute le traitement, pas besoin forcément qu'elle soit assignée par la suite. Elle exécute le traitement "sur place", simplement, dans ce cas-ci.

 

Après, concernant l'utilité, c'est surtout que - pour ma part - je n'ai pas encore été plus loin dans le Dispatcher, donc je ne sais pas te dire ce qu'il peut faire ici.

[Erikku]

Ca veut dire quoi "Aucun hook n'existe pas."?

Comme je disais dans mon premier post, "Je n'en ai trouvé aucune autre trace.", ni dans le code, ni dans la DB j'aurais pu préciser.

Ça veut seulement dire qu'un hook est disponible du moment où on l'enregistre.

Oui, donc s'il n'est pas enregistré, il n'est pas disponible, donc on peut dire qu'il n'existe pas..

En gros, tu dis que ce qui n'existe pas existe quand c'est créé.., pas mal!!

 

En réalité, [..] du moment ou un module enregistre un hook, si celui-ci n'existe pas, il est automatiquement enregistré.

Si un module engistre un hook, il est enregistré.. La encore, pas mal!

Par contre, je ne vois pas bien pourquoi il est "automatiquement enregistré" si c'est le module qui le fait.

 

Concernant le code, tu en cites toi-même:

Hook::exec('actionDispatcher', $params_hook_action_dispatcher);

C'est donc qu'il en existe une trace !

La, je vais finir pas croire que tu le fais expres..

Je disais "Je n'en ai trouvé aucune autre trace.".

Si actionDispatcher n'apparaissait vraiment nulle part, alors je n'aurais probablement pas posé la question de savoir ce qu'il faisait..

 

Tu peux donner quelques exemples [de hook dynamiques] que j'aille voir?

Les hooks dynamiques sont ceux d'ajout et d'uptate d'objets. Pour de plus amples précisions, je te conseille la lecture de mon article (disponible sur ce post)

Un nom de hook ou/et un fichier et une ligne auraient été appreciables.

 

La méthode exec() de la classe Hook exécute le traitement, pas besoin forcément qu'elle soit assignée par la suite. Elle exécute le traitement "sur place", simplement, dans ce cas-ci.

Après, concernant l'utilité, c'est surtout que - pour ma part - je n'ai pas encore été plus loin dans le Dispatcher, donc je ne sais pas te dire ce qu'il peut faire ici.

Je vois ca oui, et c'etait un peu la question de depart..

[J. Danse]

Je sais qu'il est 23h, mais je ne suis pas encore au lit et j'ai pourtant l'impression de rêver...

 

Oui, donc s'il n'est pas enregistré, il n'est pas disponible, donc on peut dire qu'il n'existe pas..

En gros, tu dis que ce qui n'existe pas existe quand c'est créé.., pas mal!!

 

Reprenons... Si du code tel que Hook::exec('nomDunHook') est présent dans le code, alors tout hook qui sera enregistré à ce dernier via sa méthode install() permettra d’interagir avec.

 

Ce que j'entends par là, c'est que du code existe bel et bien en y faisant référencé et donc il est possible que ce hook soit exécuté à cet endroit précis.

 

Ce qui n'est pas le cas des hooks nouvellement créé et utilisable seulement dans les tpl, par exemple !

 

(et là, ne me dis surtout pas que ce serait un hook nouvellement crée, par pitié !)

 

 

Par contre, je ne vois pas bien pourquoi il est "automatiquement enregistré" si c'est le module qui le fait.

 

Cela signifiait que le hook sera inséré dans la table des hooks sans avoir à recourir à un INSERT en plus comme on le faisait pour une 1.4.

 

Un nom de hook ou/et un fichier et une ligne auraient été appreciables.

 

Si je t'ai envoyé vers mon article, c'est parce qu'une explication y était donné. Mais si tu tiens à un fichier et une ligne: /classes/ObjectModel.php, L443 C5 (pour le premier hook, par exemple).

 

Et pour la mini explication, il s'agit d'un Hook qui peut-être du style: actionObjectProductAddBefore sachant que Product fait référence au nom de la classe de l'objet ajouté via add(). Tu n'en trouveras aucune trace dans la table des hooks. Pourtant, je te jure qu'ils sont existant (si si !) et utilisables en l'état, voire même bien pratique.

 

Je vois ca oui, et c'etait un peu la question de depart..

 

Je suis d'accord pour la question. Mais pas pour le postulat qui disait que ces lignes ne servaient à rien. ça, non, je ne suis pas d'accord. Je voulais seulement parler de ça.

[Broceliande]

En toute honnêteté Erriku je ne vois plus du tout ou tu veux en venir et j'ai presque l'impression que tu fais montre d'une mauvaise foi ou d'une mauvaise volonté hors du commun.

 

Un simple exemple je cite :

Un nom de hook ou/et un fichier et une ligne auraient été appreciables.

 

J.Danse a mis un lien vers un article détaillé qui explique tout ceci , que dire de plus, sinon que je n'ai pas encore eu le temps de saluer la qualité de ce dernier mais que ce sera fait !?

 

Maintenant on parlait d'exemple d'utilisation alors je vais t'en trouver un à la volée et au pif :

 

- Ce hook intervient juste avant l'affichage du controller .

- Le hook retourne le controller en paramètres , entre autre.

- Supposons donc que l'on souhaite simplement logguer les appels à ces controllers et en tirer des stats , alors on implémente ce hook dans un module , on fait notre sauce , et le tour est joué...

 

C'est minable comme exemple mais à l'instar de chaque hook , seuls ceux qui en ont besoin se rendent compte qu'il est présent et l'utilisent. La boucle est bouclée...

 

Par le passé le reproche était fait à la solution (et je suis pas le dernier à avoir pesté) de ne pas avoir suffisament de hooks...

 

Il est clair qu'aujourd'hui , chercher à en supprimer serait malvenu non ?

[Erikku]

j'ai presque l'impression que tu fais montre d'une mauvaise foi ou d'une mauvaise volonté hors du commun.

N'exagérons pas non plus.

Je posais juste une question que je pensais simple, "a quoi ca sert?" et on me reponds "ca sert mais on ne sait pas a quoi".

On va dire que je suis encore de mauvaise foi, mais il aurait suffit de me dire (si j'ai bien compris), ce hook est la au cas ou quelqu'un voudrait faire un truc a cet endroit mais pour l'instant il n'est pas utilisé. C'est tout.

 

Par le passé le reproche était fait à la solution (et je suis pas le derbier à avoir pesté) de ne pas avoir suffisament de hooks...

Il est clair qu'aujourd'hui , chercher à en supprimer serait malvenu non ?

C'est un avis. Je suis plus pour mettre du code qui est effectivement utilisé.

Et au vue des reponses, je doute que ce hook soit tres utilisé, mais c'est un autre debat.

Il pourrait, par exemple, aussi bien etre commenté, ca permettrait a ceux qui veulent faire quelque chose a cet endroit de le faire aussi simplement et ca epargnerait aux autres des appels qui ne leur servent pas.

[Broceliande]

N'exagérons pas non plus.

Je posais juste une question que je pensais simple, "a quoi ca sert?" et on me reponds "ca sert mais on ne sait pas a quoi".

On va dire que je suis encore de mauvaise foi, mais il aurait suffit de me dire (si j'ai bien compris), ce hook est la au cas ou quelqu'un voudrait faire un truc a cet endroit mais pour l'instant il n'est pas utilisé. C'est tout.

 

Une petite rectification s'impose : nous n'avons absolument pas dit que nous ne savions pas à quoi servait ce hook, mais seulement que nous n'avions pas sur le coup d'exemple d'usage...

En revanche ce qui est parfaitement exact, c'est que ce hook est effectivement là pour le cas ou l'on souhaiterait intervenir à cet endroit.

 

C'est un avis. Je suis plus pour mettre du code qui est effectivement utilisé.

Et au vue des reponses, je doute que ce hook soit tres utilisé, mais c'est un autre debat.

Il pourrait, par exemple, aussi bien etre commenté, ca permettrait a ceux qui veulent faire quelque chose a cet endroit de le faire aussi simplement et ca epargnerait aux autres des appels qui ne leur servent pas.

 

Là je suis contraint de dire non , non , et re non!

L'essence même des hooks est de pouvoir exécuter un code externe à un moment donné du traitement, sans avoir à modifier le code natif.

Commenter les hooks potentiellement non exploités revient à perdre tout ce pour quoi ils existent.

Imagine une seconde ce qui se passerait si pour utiliser tel ou tel hook, on devait décommenter des lignes de code natif !

"Pour utiliser ce module , décommentez les lignes xx et yy du fichier lambda.php, puis les lignes zzz etc ... " : et encore , on ne parle pas des différente versions qui peuvent donc donner lieu à une variation ...

Ca me rappelle de très mauvais souvenirs sur l'installation de modules sur les osc....

Pour le coup toute mise à jour impliquerait d'avoir à refaire la manip...

 

Je pense que la nature même des hooks t'échappe encore quelque peu (je me trompe ? ).

Je n'ai jamais vraiment trouvé le terme idéal au demeurant.

Mais clairement, les appels aux hooks dans le core sont indispensables à la création de fonctionnalités supplémentaires.

Si aucun module n'est accroché au hook , alors l'appel consomme des ressources négligeables, d'autant que la liste des modules 'accrochés' aux hooks est mise en cache.

 

Au sujet des commentaires d'ailleurs, un puriste te dirait qu'ils n'existent que pour apporter des informations au code, et en aucun cas à occulter/désactiver des lignes de code.

Un code source qui comprend des blocs ou lignes de code commentées est généralement un code inachevé ou perfectible.

 

Bref en résumé et pour conclure, utilisés ou non , les hooks sont là à dessein et il est bien plus gènant d'avoir à intervenir sur un traitement qui n'appelle aucun hook que d'avoir un appel inutilisé.