J'ai un behaviour (dans class.dc.blog.php) qui ressemble à ceci :                $this->core->callBehavior('coreBlogBeforeGetPosts',$params); Comment puis-je faire pour que la fonction appelée puisse modifier un des éléments du tableau $params ?

> Dans ton besoin exprimé dans le ticket demandant cet ajout, quels sont > les appelants que tu voudrais voir ? Je pense qu'il serait préférable > de remplacer ce behavior par des behaviors dans les appelants, voire > modifier le code de tpl:Entries, où on est sûr que les behaviors sont > coté public. ... je pense notamment au ticket http://dev.dotclear.org/2.0/ticket/924 qui en parle...

J'ai un plugin sur le feu qui permet de préciser l'ordre d'affichage des billets en fonction de la catégorie (et uniquement dans le contexte catégorie). Pour faire ça j'ai codé un behaviour qui remplit (ou modifie) le $params['order'] en fonction des réglages effectués côté admin du plugin. Sauf qu'en l'état l'élément du tableau modifié (avec succès par ma fonction, j'ai tracé ça) n'est pas rémanent une fois de retour après l'appel. D'où ma question. En gros je trouvais qu'un behaviour dispo à ce niveau permettait de jouer avec les $params juste avant que ce ne soit transformé en requête SQL.

Le 18 novembre 2011 12:58, Dsls <dsls(a)morefnu.org&gt; a écrit : >> J'ai un plugin sur le feu qui permet de préciser l'ordre d'affichage >> des billets en fonction de la catégorie (et uniquement dans le >> contexte catégorie). Pour faire ça j'ai codé un behaviour qui remplit >> (ou modifie) le $params['order'] en fonction des réglages effectués >> côté admin du plugin. Sauf qu'en l'état l'élément du tableau modifié >> (avec succès par ma fonction, j'ai tracé ça) n'est pas rémanent une >> fois de retour après l'appel. D'où ma question. >> >> En gros je trouvais qu'un behaviour dispo à ce niveau permettait de >> jouer avec les $params juste avant que ce ne soit transformé en >> requête SQL. > > Il s'agit donc bien d'un souhait de changement de comportement coté > public. L'emplacement du behavior me semble donc mal positionné, vu > que dans ton cas, il risque d'avoir pas mal d'effets de bord. > Certes, on s'en sort un peu si tu surcharges le behavior dans le > _public.php de ton plugin, la surcharge ne se fera que coté public du > blog, mais tout appel à getPosts coté public sera modifié par ton > plugin... > > J'allais proposer de le placer directement dans class.dc.template.php, > mais mon brouillon d'autre mail me fait changer le fusil d'épaule. > > Attends-donc mon prochain mail sur la list, pour un sujet plus global... Ok je remets mon plugin dans sa boîte en attendant la suite…

> Cela dit, juste pour savoir, hormis en passant par un ArrayObject il > n'y a pas de moyen de modifier le tableau passé en paramètre d'un > behaviour ? Non, car la gestion de behaviors passe par func_get_args/call_user_func_array, qui refuse de forcer le passage des variables par référence.

Ok donc en l'espèce le behaviour que j'ai introduit ne sert probablement à rien du tout. À virer d'ici la prochaine release, donc.

Sauf que dans le cas qui me préoccupe, la variable $params n'est qu'un simple array(). De plus je viens de m'apercevoir que j'ai au passage oublié de mettre à jour le $_ctx->post_params au retour de l'appel du behaviour, ce qui pourrait également provoquer des effets de bord.