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 <[email protected]> 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 - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
