Priorisation des behaviors

[bruno]

Actuellement, lors d'un $core->callBehavior les behaviors sont exécutées dans leur ordre de déclaration. Il pourrait être intéressant de pouvoir spécifier, lors du addBehavior, à quelle position l'ajouter, ou a défaut permettre d'ajouter en début ou en fin de behavior.

Cas concret : si on souhaite modifier le tpl EntryContent? de manière à rendre son rendu sélectif, en générant :

• "if(...):" dans le behavior templateBeforeBlock
• et "else: [code de remplacement]; endif;" dans templateAfterBlock

Dans ce cas, il est préférable d'ajouter le behavior templateBeforeBlock en premier, et le behavior templateAfterBlock en dernier, pour éviter des erreurs de code si plusieurs plugins implémentent ces behaviors d'une manière similaire.

L'idée serait de rajouter un paramètre booleen $prepend (valeur par défaut : false) à la méthode core->addBehavior. S'il est à true, le behavior est ajouté en début de liste

[olivier]

L'ordre de priorité des plugins n'est pas suffisant ? C'est bien beau permettre de dire "c'est moi le premier" mais si tout le monde le fait, le problème reste entier :)

[bruno]

Oui et non : si l'ajout se fait toujours à la fin, on risque d'imbriquer des conditions dans le mauvais sens. Si le plugin 1 ajoute :

• En templatebeforeblock : "if():"
• En templateafterblock : "endif;"

Et si le plugin 2 ajoute :

• En templatebeforeblock : "while();"
• En templateafterblock : "endwhile;"

L'ordre de priorité des plugins ne changera rien, vu que les behaviors de chaque plugin sont enregistrées d'un coup, au moment du require du _public.php.

On va avoir un code final qui ressemblera soit à "if():while():endif;endwhile", soit à "while():if():endwhile;endif;", et donc un code invalide.

Si maintenant les plugins font comme suit : Si le plugin 1 ajoute :

• En templatebeforeblock : "if():" (prepend)
• En templateafterblock : "endif;" (append)

Et si le plugin 2 ajoute :

• En templatebeforeblock : "while();" (prepend)
• En templateafterblock : "endwhile;" (append)

Quelque soit le plugin qui arrive en premier, on aura un code php généré valide, avec les bonnes imbrications, ie soit 'if|while|endwhile|endif" si le plugin 1 passe en premier, soit "while|if|endif|endwhile" si le plugin 2 passe en premier... en jouant sur les priorités, on peut même dire qui passe en premier, du coup :)

Je suis plus clair, là ?

[olivier]

Ah wé... c'est pas terrible de faire un truc pareil quand même :)

[bruno]

Il y a peut-être un autre moyen : le besoin initial est de remplacer "à la volée" le tpl:EntryContent pour certains post-type, sans pour autant toucher au template... pour le moment l'encapsulation dans les template[before|after]block marche, mais si un autre plugin a cette idée, ça casse tout :)

[biou]

soit j'ai pas compris, soit ca m'a l'air bien compliqué ! :)

[jcdubacq]

Si j'ai bien compris le problème, j'ai dû écrire un plugin pour ça. J'avais plusieurs plugin qui réécrivaient à la volée le EntryContent? et le EntryExcerpt?...  http://jean-christophe.dubacq.fr/post/stacker

[JcDenis]

(j'avais pa lu celui la)

Dans ce que je lis au dessus, il faut que les bouts de codes qui ont un xxxBeforexxx lisent la liste des xxxAfterxxx dans l'ordre inverse pour ne pas mélanger les boucles, alors pourquoi ne pas ajouter simplement un argument à $core->callBehavior();

ex: $core->callbehavior(name,reverse=false);

Le Core sert la liste dans un ordre ou dans l'autre suivant la demande. C'est pas plus simple, nan? Après la priorité des plugins devrait suffir pour le reste.