En fait après réflexion, comme dit Nicolas c'est tôt la matin, le pb que
j'ai est plutôt du côté des behaviours comme le précise Bruno.
Je vais reprendre tout ça à tête reposée tout à l'heure.
Le 16 janvier 2015 08:24, Bruno <dsls(a)morefnu.org> a écrit :
Utiliser la priorité (dans le _define.php) peut aider dans certains
cas,
> mais je suis en ce moment confronté à un cas où il faut, dans un plugin,
> que je passe avant (définition d'une macro wiki) ET après (init d'un
> bouton) un autre plugin (éditeur). Du coup ce n'est pas applicable.
>
Pas sûr de comprendre le problème. Il faut distinguer le moment où on
déclare l'ensemble des actions d'un behavior (via addBehavior), et le
moment ou ce behavior est appelé (via callBehavior). Il faut bien entendu
que les actions soient toutes définies avant le callbehavior().
Je pense que ton souci vient du fait que dcLegacyEditor appelle
coreInitWikiPost dans son _admin.php. Pour autant un plugin ne doit pas
être prioritaire face à dcLegacyEditorpour s'il agit sur coreInitWikiPost,
il "suffit" de faire le addBehavior dans son _prepend.php (qui et chargé
avant tout les _admin.php).
Du coup une nouvelle boucle qui appellerait cette fois le _append.php (s'il
> existe) de chaque plugin, construit de la même manière qu'un
_prepend.php :
>
Je ne suis pas fan de l'ajout d'un fichier en plus de ce type, cela
ajouterait de la confusion pour les devs, et pas mal de cas particuliers à
gérer en plus. D'autant que je ne suis pas sûr que ça gère tous les cas.
S'il faut vraiment qu'on gère ce genre de choses, je serais plutôt partisan
de pouvoir ajouter des priorités (facultatives) au sein de addBehavior.
Voir ce ticket qui date de 7 ans et qu'olivier avait refusé :
http://dev.dotclear.org/2.0/ticket/523.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev